Force the client to use one specific EAP method
As Matthew suggested, I've removed the configurations for the others EAP methods, indeed now they don't work anymore. But, as Matthew already said, the clients will always choose whatever method they want to use or in the most cases the chosen method is the one set on the supplicant configuration file. I thought of making a script that would change the 802.1x configuration of the supplicant, but then every client should download and run the script, which is no practical at all. So, any other workaround that you're aware of? I was wondering if adding a realm could help somehow. Luca
Hi,
As Matthew suggested, I've removed the configurations for the others EAP methods, indeed now they don't work anymore.
But, as Matthew already said, the clients will always choose whatever method they want to use or in the most cases the chosen method is the one set on the supplicant configuration file.
I thought of making a script that would change the 802.1x configuration of the supplicant, but then every client should download and run the script, which is no practical at all.
So, any other workaround that you're aware of?
I was wondering if adding a realm could help somehow.
Why the effort? The client can initially *suggest* whatever it likes. The server will NAK it and tell the client what EAP method to use instead. This is one round-trip. It happens automatically in the background, no UI or disruption involved. So, what's the win in writing complicated things on the supplicant? One of the few things which work very nicely in EAP is the method auto-negotiation. :-) Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi Stefan, thank you for the reply.
Why the effort? The client can initially *suggest* whatever it likes. The server will NAK it and tell the client what EAP method to use instead.
Exactly, after the client *suggest* which method would like to use, anyway to make the server tell the client to use one specific EAP method instead?
So, what's the win in writing complicated things on the supplicant?
Well, unfortunately it was the only and impractical idea I came up with.
One of the few things which work very nicely in EAP is the method auto-negotiation. :-)
Yes but for what I'm trying to accomplish I really need to address the negotiation to one specific method :-) Luca ________________________________ From: Freeradius-Users <freeradius-users-bounces+sfire=hotmail.it@lists.freeradius.org> on behalf of Stefan Winter <stefan.winter@restena.lu> Sent: Wednesday, April 12, 2017 1:28 PM To: FreeRadius users mailing list Subject: Re: Force the client to use one specific EAP method Hi,
As Matthew suggested, I've removed the configurations for the others EAP methods, indeed now they don't work anymore.
But, as Matthew already said, the clients will always choose whatever method they want to use or in the most cases the chosen method is the one set on the supplicant configuration file.
I thought of making a script that would change the 802.1x configuration of the supplicant, but then every client should download and run the script, which is no practical at all.
So, any other workaround that you're aware of?
I was wondering if adding a realm could help somehow.
Why the effort? The client can initially *suggest* whatever it likes. The server will NAK it and tell the client what EAP method to use instead. This is one round-trip. It happens automatically in the background, no UI or disruption involved. So, what's the win in writing complicated things on the supplicant? One of the few things which work very nicely in EAP is the method auto-negotiation. :-) Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Wed, Apr 12, 2017 at 12:06:26PM +0000, LUCA wrote:
One of the few things which work very nicely in EAP is the method auto-negotiation. :-)
Yes but for what I'm trying to accomplish I really need to address the negotiation to one specific method :-)
You've already done that by limiting the EAP methods on the server. If the device can't connect now then it's device configuration as you said. Yes, people do that with setup or onboarding tools. That's just the way it is. Look at it in a good way - at least you can make sure all clients have the correct CA trust and security settings. Manually configured devices are notoriously bad at this. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
You've already done that by limiting the EAP methods on the server. If the device can't connect now then it's device configuration as you said.
Yes, now the device can't connect because it does try to use one method no longer configured on the server. But there is no way, during the negotiation process, to make the server tell the client to use one specific EAP method?
Yes, people do that with setup or onboarding tools. That's just the way it is. Look at it in a good way - at least you can make sure all clients have the correct CA trust and security settings. Manually configured devices are notoriously bad at this.
Yes, definitely not manually configured devices. I'm trying to leave the configuration tool as last option. As I already said it would be impractical. Without mentioning the massive disservice this will bring in the first few weeks. Luca ________________________________ From: Freeradius-Users <freeradius-users-bounces+sfire=hotmail.it@lists.freeradius.org> on behalf of Matthew Newton <mcn4@leicester.ac.uk> Sent: Wednesday, April 12, 2017 2:42 PM To: FreeRadius users mailing list Subject: Re: Force the client to use one specific EAP method On Wed, Apr 12, 2017 at 12:06:26PM +0000, LUCA wrote:
One of the few things which work very nicely in EAP is the method auto-negotiation. :-)
Yes but for what I'm trying to accomplish I really need to address the negotiation to one specific method :-)
You've already done that by limiting the EAP methods on the server. If the device can't connect now then it's device configuration as you said. Yes, people do that with setup or onboarding tools. That's just the way it is. Look at it in a good way - at least you can make sure all clients have the correct CA trust and security settings. Manually configured devices are notoriously bad at this. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html FreeRADIUS -- users' list info<http://www.freeradius.org/list/users.html> www.freeradius.org Users' List Information. The freeradius-users mailing list is for users of the FreeRADIUS server not Cistron's server! There are a few house-rules to which we'd like ...
On Wed, Apr 12, 2017 at 02:00:40PM +0000, LUCA wrote:
You've already done that by limiting the EAP methods on the server. If the device can't connect now then it's device configuration as you said.
Yes, now the device can't connect because it does try to use one method no longer configured on the server.
Right. Configure the device.
But there is no way, during the negotiation process, to make the server tell the client to use one specific EAP method?
I'm really not sure how many times we have to say that the choice of EAP method is up to the device, not FreeRADIUS. There is no amount of poking or prodding FreeRADIUS that will fix this.
Yes, definitely not manually configured devices. I'm trying to leave the configuration tool as last option. As I already said it would be impractical. Without mentioning the massive disservice this will bring in the first few weeks.
It sounds like you don't like the answer you're getting. Sorry. If you invent a better way I'm sure everyone else will be quite happy to know. Until then, you have two options 1. configure FreeRADIUS to use the type of auth that the devices want to use; 2. reconfigure the devices. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
First, let me thank you for the explanations so far. Maybe I found a "solution". The Access-Challenge packet contains an EAP Request in which it is specified the EAP method that the supplicant should use. So I was thinking that maybe I could edit the EAP Request with an EAP method of my choosing, using for instance scapy. Of course the client could still NAK it and reply with another EAP method. By the way, which could be the exact reason for a client to NAK the suggested EAP method? Shouldn't the supplicant support almost all the EAP methods suggested from the server? Luca ________________________________ From: Freeradius-Users <freeradius-users-bounces+sfire=hotmail.it@lists.freeradius.org> on behalf of Matthew Newton <mcn4@leicester.ac.uk> Sent: Wednesday, April 12, 2017 6:59 PM To: FreeRadius users mailing list Subject: Re: Force the client to use one specific EAP method On Wed, Apr 12, 2017 at 02:00:40PM +0000, LUCA wrote:
You've already done that by limiting the EAP methods on the server. If the device can't connect now then it's device configuration as you said.
Yes, now the device can't connect because it does try to use one method no longer configured on the server.
Right. Configure the device.
But there is no way, during the negotiation process, to make the server tell the client to use one specific EAP method?
I'm really not sure how many times we have to say that the choice of EAP method is up to the device, not FreeRADIUS. There is no amount of poking or prodding FreeRADIUS that will fix this.
Yes, definitely not manually configured devices. I'm trying to leave the configuration tool as last option. As I already said it would be impractical. Without mentioning the massive disservice this will bring in the first few weeks.
It sounds like you don't like the answer you're getting. Sorry. If you invent a better way I'm sure everyone else will be quite happy to know. Until then, you have two options 1. configure FreeRADIUS to use the type of auth that the devices want to use; 2. reconfigure the devices. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html FreeRADIUS -- users' list info<http://www.freeradius.org/list/users.html> www.freeradius.org Users' List Information. The freeradius-users mailing list is for users of the FreeRADIUS server not Cistron's server! There are a few house-rules to which we'd like ...
On Apr 19, 2017, at 8:58 AM, LUCA <sfire@hotmail.it> wrote:
First, let me thank you for the explanations so far.
Maybe I found a "solution".
The Access-Challenge packet contains an EAP Request in which it is specified the EAP method that the supplicant should use. So I was thinking that maybe I could edit the EAP Request with an EAP method of my choosing, using for instance scary.
You're still stuck on what you want to do. Your wishes are nice, but they're just wishes. The limiting factor here is what the client can do.
Of course the client could still NAK it and reply with another EAP method.
By the way, which could be the exact reason for a client to NAK the suggested EAP method? Shouldn't the supplicant support almost all the EAP methods suggested from the server?
No. The clients typically support 2-3 EAP methods. What you want is easy if you write your own EAP supplicant software. Otherwise, it's pretty much impossible. Now please believe us, and stop trying to do the impossible. It's impossible. Alan DeKok.
On Wed, Apr 19, 2017 at 12:58:28PM +0000, LUCA wrote:
The Access-Challenge packet contains an EAP Request in which it is specified the EAP method that the supplicant should use. So I was thinking that maybe I could edit the EAP Request with an EAP method of my choosing, using for instance scapy.
That's basically what the default eap method configuration does.
Of course the client could still NAK it and reply with another EAP method.
It likely will, unless it is already configured to use the method that the server suggested.
By the way, which could be the exact reason for a client to NAK the suggested EAP method?
Because it doesn't want to use the method that the server suggests.
Shouldn't the supplicant support almost all the EAP methods suggested from the server?
No. It uses whatever has been configured on the client. Sorry, but I'm done on this. You're not listening, so there's no point repeating myself every time. There is no getting around the fact that you are going to have to configure the client devices if you want to set the EAP method that you want them to use. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (4)
-
Alan DeKok -
LUCA -
Matthew Newton -
Stefan Winter