I'm getting ready to implement EAP-TLS for 802.1x port authentication. Everything works great in my testing environment and I'm very happy with it. However, before we roll it out into production, I must write a set of recovery procedures. In these procedures I need to include a section on the (admittedly very rare) chance that authentications start failing across the board for some reason - for example, if we accidently let a bunch of the user certificates expire, all of those machines will fail port-authentication until the certificates are replaced. My management would like a way to force authorization to succeed even if EAP has actually failed. My thought is to use a module that really does nothing but authenticate and authorize everything it sees. I've investigated the rlm_always, rlm_exec and rlm_perl modules but I can't seem to figure out how to do anything but report "handled" or "ok." This does not seem to result in an Access-Accept message being sent. Any suggestions? I'm using the latest FreeRadius 2 - the config files are unchanged except for the eap.conf (to specify the Root cert and server cert) and I am using a sparse sites-enabled file: client x.x.x.x { secret = secret server = EAP_Server } server EAP_Server { authorize { eap } authenticate { eap }
Danny Paul wrote:
My management would like a way to force authorization to succeed even if EAP has actually failed.
This is impossible. It is *designed* to be impossible. If it was possible, malicious networks could tell users that "authentication succeeded", and then attack the users. You need to look at your NAS documentation for something like "fallback VLAN" support. Some NASes have the ability to put users into special VLANs in some circumstances. In any case, the solution is much more complicated than just changing the FreeRADIUS configuration (which won't do anything) Alan DeKok.
Alan DeKok wrote:
Danny Paul wrote:
My management would like a way to force authorization to succeed even if EAP has actually failed.
This is impossible. It is *designed* to be impossible. If it was possible, malicious networks could tell users that "authentication succeeded", and then attack the users.
You need to look at your NAS documentation for something like "fallback VLAN" support. Some NASes have the ability to put users into special VLANs in some circumstances.
If this is a wired port then just force an Access-Accept, yes it breaks the RFC but if your NAS doesn't inspect the contents of the EAP-Message then it'll work.
In any case, the solution is much more complicated than just changing the FreeRADIUS configuration (which won't do anything)
Thanks, Arran
If this is a wired port then just force an Access-Accept, yes it breaks the RFC but if your NAS doesn't inspect the contents of the EAP-Message then it'll work.
I would think that would work, I just don't know how to do that! It's really easy to create a module that returns "ok" or "handled" but, despite hours of pouring through the unlange manpages and documentation on rlm_example, rlm_perl, and rlm_exec, I cannot seem to create a module that will compel the RADIUS server to send back an Access-Accept. Mr. DeKok says this is impossible, and he would probably be the one to know. I'll keep investigating another way around this and update the list if I find anything. In the mean time, if anyone else thinks of something, please let me know.
Thanks, Arran
No no, thank you!
Hi,
I would think that would work, I just don't know how to do that! It's really easy to create a module that returns "ok" or "handled" but, despite hours of pouring through the unlange manpages and documentation on rlm_example, rlm_perl, and rlm_exec, I cannot seem to create a module that will compel the RADIUS server to send back an Access-Accept. Mr. DeKok says this is impossible, and he would probably be the one to know. I'll keep investigating another way around this and update the list if I find anything. In the mean time, if anyone else thinks of something, please let me know.
you can use eg the Users file to send an accept - however, the 'impossible' bit didnt refer to FreeRADIUS - but to the end equipment and the EAP specification. dumb and/or broken NAS devices can receive a basic accept message...but anything that has even an ounce of security will expect the full EAP transaction to occur (cert checks, challenge response etc) not just a 'yep, alls okay, come on in!' message. imagine if you went to a shop and your credit card was just accepted without the PIN (or swipe + signature for those non-PIN places) would you feel comfortable? you shouldnt..and neither should your OS so, whilst you could do crazy things like accept by default, the NAS or the end device might - and should, ignore and reject that when EAP is involved it'd be better to just change the VLAN settings so guest/fail have full access for the day alan
Danny Paul wrote:
I would think that would work, I just don't know how to do that! It's really easy to create a module that returns "ok" or "handled" but, despite hours of pouring through the unlange manpages and documentation on rlm_example, rlm_perl, and rlm_exec, I cannot seem to create a module that will compel the RADIUS server to send back an Access-Accept.
update control { Response-Packet-Type := Access-Accept } Where this goes depends on your local configuration. It's undocumented because it's a horrible thing to do. And almost everyone using it will get it wrong. Alan DeKok.
update control { Response-Packet-Type := Access-Accept }
Where this goes depends on your local configuration.
It's undocumented because it's a horrible thing to do. And almost everyone using it will get it wrong.
Perhaps I'll try it anyway. Again, we're talking about emergency situations only so we hopefully wouldn't be doing a "horrible thing" for too awfully long. Thanks everyone for their help.
On Sat, Oct 18, 2008 at 04:07:27PM +0100, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Danny Paul wrote:
My management would like a way to force authorization to succeed even if EAP has actually failed.
This is impossible. It is *designed* to be impossible. If it was possible, malicious networks could tell users that "authentication succeeded", and then attack the users.
You need to look at your NAS documentation for something like "fallback VLAN" support. Some NASes have the ability to put users into special VLANs in some circumstances.
If this is a wired port then just force an Access-Accept, yes it breaks the RFC but if your NAS doesn't inspect the contents of the EAP-Message then it'll work.
Are you sure? Won't the supplicant barf because mutual authentication doesn't succeed?
Hi,
The supplicant will barf, and yet, the machine will not ignore the wide open network port.
That would be supplicant-dependent, right? For example the Intel supplicant which I tried some time ago had a very solid opinion about what was going on and I couldn't use the net "just like that". OTOH, there is this peculiarity in the IEEE 802.1X standard itself that basically says the supplicant tries three times to authenticate with EAP-Identity, and after that shall "assume that the port is open". Maybe that's what happens. Anyway, it is a *very* bad idea to rely on such behaviour. I suggest a bucket of cold water into the face of the guy's management. An authentication server is used to authenticate users, not to non-authenticate users. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
That would be supplicant-dependent, right? For example the Intel supplicant which I tried some time ago had a very solid opinion about what was going on and I couldn't use the net "just like that". OTOH, there is this peculiarity in the IEEE 802.1X standard itself that basically says the supplicant tries three times to authenticate with EAP-Identity, and after that shall "assume that the port is open". Maybe that's what happens.
Well that is true, I guess I'm only familiar with Windows supplicants.
Anyway, it is a *very* bad idea to rely on such behaviour. I suggest a bucket of cold water into the face of the guy's management. An authentication server is used to authenticate users, not to non-authenticate users.
Once again, we're not relying on it - this is an emergency procedure, to be used in emergencies only. We're talking about availability as a component of security here. There is nothing wrong with a documented, tested plan for an emergency situation.
Greetings,
Stefan Winter
Hi,
That would be supplicant-dependent, right? For example the Intel supplicant which I tried some time ago had a very solid opinion abou Well that is true, I guess I'm only familiar with Windows supplicants.
The Intel supplciant *is* for Windows. It comes coupled with Centrino chipsets and is a lot more usable than the *built-in* supplicant that comes with the OS. I say this just to make you aware that you may be badly advised if you do your non-conformance tests only against the XP/Vista built-in supplicant. Unless your corporate environment is locked down so that it prevents this supplicant from being installed, you should be very careful about the assumptions you have about your end-users equipment. Do you have any other devices that need network access? How about PDAs? SymbianOS, maybe even some freaky Linux users?
Anyway, it is a *very* bad idea to rely on such behaviour. I suggest a bucket of cold water into the face of the guy's management. An authentication server is used to authenticate users, not to non-authenticate users.
Once again, we're not relying on it - this is an emergency procedure, to be used in emergencies only. We're talking about availability as a component of security here. There is nothing wrong with a documented, tested plan for an emergency situation.
As you wish. Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Hi,
If this is a wired port then just force an Access-Accept, yes it breaks the RFC but if your NAS doesn't inspect the contents of the EAP-Message then it'll work.
Well... a sane supplicant, be it on a wireless or wired port, will maintain its EAP state machine, and will alert the user if the state machine was violated, right? So if the NAS gets and sends on a EAPoL-Success out of order, client gear will yell. Or did I get you wrong? Stefan
In any case, the solution is much more complicated than just changing the FreeRADIUS configuration (which won't do anything)
Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Well... a sane supplicant, be it on a wireless or wired port, will maintain its EAP state machine, and will alert the user if the state machine was violated, right? So if the NAS gets and sends on a EAPoL-Success out of order, client gear will yell. Or did I get you wrong?
My experience was as follows: Cisco 2950 switch has an "auth fail" vlan option. If port authentication fails, the port is marked authorized and put in the configured auth-fail vlan as opposed to the default vlan or remaining in an unauthorized state. For Windows XP SP2, if authentication fails, the user is notified - however, network communications across that vlan works fine. Additionally, consider this: a packet capture reveals that, even after authentication has failed, Windows XP SP2 will send out DHCP requests. Evidently the supplicant is somehow decoupled from the other processes involved in bringing up a network interface.
Hi,
Cisco 2950 switch has an "auth fail" vlan option. If port authentication fails, the port is marked authorized and put in the configured auth-fail vlan as opposed to the default vlan or remaining in an unauthorized state. For Windows XP SP2, if authentication fails, the user is notified - however, network communications across that vlan works fine.
So, what means "port authentication fails"? An Access-Reject? Well what you were trying to do was send an Access-Accept no matter what, which is for an authenticator a reason to count it as success, and will subsequently not put a user in a auth fail VLAN.
Additionally, consider this: a packet capture reveals that, even after authentication has failed, Windows XP SP2 will send out DHCP requests. Evidently the supplicant is somehow decoupled from the other processes involved in bringing up a network interface.
SP3? Vista? Nokia N95? iPhone 3G? Make a list of stuff to test... Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
This is impossible. It is *designed* to be impossible. If it was possible, malicious networks could tell users that "authentication succeeded", and then attack the users.
I'm not sure you grasped what I was after - imagine a 802.1x wired switch, supplicants and RADIUS server configured for EAP-TLS. This works fine until the clumsy network administrator forgets to renew the certificates for each of his supplicants and they all expire on the same day. On that particular day, instead of spending hours getting new certificates issued, I'd rather change something in the RADIUS server config file to send out access-accept messages to every request. My users would be functional for the day while I go about generating new certificates one at a time. Yes, the switch would be "wide open" for the day - but that's better than completely shut down in management's opinion.
You need to look at your NAS documentation for something like "fallback VLAN" support. Some NASes have the ability to put users into special VLANs in some circumstances.
Oh yes, most gear does, and we're implementing that as well - however, the "guest vlan" or "auth-fail vlan" will have limited access to network resources so that doesn't help us out of this bind.
In any case, the solution is much more complicated than just changing the FreeRADIUS configuration (which won't do anything)
I would imagine that one could write a module that did nothing but authorize absolutely anything, compelling the server to send an Access-Accept message no matter what. In conjunction with the situation described above - in the rare chance that I needed to use it, I could change my config file for the day, then change it back once my problems were solved. But hey, if it's impossible then it's impossible. This being open source software I can change that myself, I suppose.
Alan DeKok.
Thank you, I thoroughly appreciate your work on this project
Danny Paul wrote:
I'm not sure you grasped what I was after
Yes, I understood. This kind of request has come up before on this list. For *wireless*, it's impossible, because the supplicant && NAS use encryption keys derived from the EAP-TLS exchange. No exchange means no keys. For wired... maybe it works. But it's an accident, and may change from switch revision to revision.
Yes, the switch would be "wide open" for the day - but that's better than completely shut down in management's opinion.
Or, you could put procedures in place to warn you about expiring certificates.
Oh yes, most gear does, and we're implementing that as well - however, the "guest vlan" or "auth-fail vlan" will have limited access to network resources so that doesn't help us out of this bind.
"guest vlan" is just a name. If your network is so bad that all of the certificates have expired, making the "guest vlan" the same as the "normal vlan" isn't a problem.
But hey, if it's impossible then it's impossible. This being open source software I can change that myself, I suppose.
Er... no. For wireless authentication, it's impossible because it's... impossible. See cryptographic research for the current meaning of "impossible" as it pertains to the encryption protocols used here. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For wired... maybe it works. But it's an accident, and may change from switch revision to revision.
Just re-read RFC 3579, it should always work (I was surprised too). RFC 3579: 2.6.3. Conflicting Messages The NAS MUST make its access control decision based solely on the RADIUS Packet Type (Access-Accept/Access-Reject). The access control decision MUST NOT be based on the contents of the EAP packet encapsulated in one or more EAP-Message attributes, if present. ... If the NAS receives an Access-Accept with an encapsulated EAP Failure, it will grant access to the peer. However, on receiving an EAP Failure, the peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access. The current default behaviour for Windows and Mac OSX is not to block traffic on the interface even if authentication fails.
Yes, the switch would be "wide open" for the day - but that's better than completely shut down in management's opinion.
Or, you could put procedures in place to warn you about expiring certificates.
Oh yes, most gear does, and we're implementing that as well - however, the "guest vlan" or "auth-fail vlan" will have limited access to network resources so that doesn't help us out of this bind.
"guest vlan" is just a name. If your network is so bad that all of the certificates have expired, making the "guest vlan" the same as the "normal vlan" isn't a problem.
But hey, if it's impossible then it's impossible. This being open source software I can change that myself, I suppose.
Er... no.
For wireless authentication, it's impossible because it's... impossible. See cryptographic research for the current meaning of "impossible" as it pertains to the encryption protocols used here.
Yeah the dynamic keying won't work... This will only ever work on wired connections. Regards, Arran - -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj8lIYACgkQcaklux5oVKInaQCffhGv8yPKtkh72uYoKZPdzKn2 bvcAoIDpp7cI1hxALo+xFwRvoxkI1aNp =rFsD -----END PGP SIGNATURE-----
Yes, the switch would be "wide open" for the day - but that's better than completely shut down in management's opinion.
Or, you could put procedures in place to warn you about expiring certificates.
Already in place. The example of expired certificates is just one possibility.
"guest vlan" is just a name. If your network is so bad that all of the certificates have expired, making the "guest vlan" the same as the "normal vlan" isn't a problem.
The network is not "that bad." Recovery procedures, such as what to do if you finally find yourself in a situation such as this keep the network from being "that bad." And without getting into too many details, there would be no easy way to change the access of the "guest vlan" or whatever terminology you want to use so that more network resources could be accessed.
Yeah the dynamic keying won't work... This will only ever work on wired connections.
Agreed. Still talking about wired only. Now that we're all in agreement that this is technically possible, even if it is a terrible idea, on to how to do it. I've had one vote for the users file, I think that would work just fine and I think I'll test that out later on today. Thanks for your reply.
It'd be a bit more complicated than simply changing an access list, unfortunately. No reason to get into details, but that's not really an option. Thanks anyway.
On 10/20/2008 at 11:32 AM, in message <20081020163223.GB22973@lboro.ac.uk>, <A.L.M.Buxey@lboro.ac.uk> wrote: Hi,
And without getting into too many details, there would be no easy way to change the access of the "guest vlan" or whatever terminology you want to use so that more network resources could be accessed.
you cant change the guest VLAN access list or policy? pity.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sun, Oct 19, 2008 at 12:49:30PM -0500, Danny Paul wrote:
This is impossible. It is *designed* to be impossible. If it was possible, malicious networks could tell users that "authentication succeeded", and then attack the users.
I'm not sure you grasped what I was after - imagine a 802.1x wired switch, supplicants and RADIUS server configured for EAP-TLS. This works fine until the clumsy network administrator forgets to renew the certificates for each of his supplicants and they all expire on the same day. On that particular day, instead of spending hours getting new
Set the clock on your server backwards.
Eating humble pie for a day would reset the admins expectations on how to handle customer expectations to a reasonable level I'd think... Sent from my iPhone On 19 Oct 2008, at 18:49, "Danny Paul" <JDPAUL@gocolumbiamo.com> wrote:
This is impossible. It is *designed* to be impossible. If it was possible, malicious networks could tell users that "authentication succeeded", and then attack the users.
I'm not sure you grasped what I was after - imagine a 802.1x wired switch, supplicants and RADIUS server configured for EAP-TLS. This works fine until the clumsy network administrator forgets to renew the certificates for each of his supplicants and they all expire on the same day. On that particular day, instead of spending hours getting new certificates issued, I'd rather change something in the RADIUS server config file to send out access-accept messages to every request. My users would be functional for the day while I go about generating new certificates one at a time.
Yes, the switch would be "wide open" for the day - but that's better than completely shut down in management's opinion.
You need to look at your NAS documentation for something like "fallback VLAN" support. Some NASes have the ability to put users into special VLANs in some circumstances.
Oh yes, most gear does, and we're implementing that as well - however, the "guest vlan" or "auth-fail vlan" will have limited access to network resources so that doesn't help us out of this bind.
In any case, the solution is much more complicated than just changing the FreeRADIUS configuration (which won't do anything)
I would imagine that one could write a module that did nothing but authorize absolutely anything, compelling the server to send an Access-Accept message no matter what. In conjunction with the situation described above - in the rare chance that I needed to use it, I could change my config file for the day, then change it back once my problems were solved.
But hey, if it's impossible then it's impossible. This being open source software I can change that myself, I suppose.
Alan DeKok.
Thank you, I thoroughly appreciate your work on this project
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Anders Holm -
Arran Cudbard-Bell -
Danny Paul -
Phil Mayers -
Stefan Winter