RADIUS message format needed to trigger EAP-TLS/EAP-TTLS negotiation
I'm working with an embedded device that needs to authenticate to a FreeRADIUS server using EAP-TLS or EAP-TTLS. I don't control the FreeRADIUS server (this means I can't provide debug output, sorry), I just need to authenticate to it from the device, with the server configured to talk EAP-TLS/EAP-TTLS. The device runs custom software that talks RADIUS, EAP, and TLS, but no matter what I try, I can't find the right combination of messages to get the server to negotiate one of the two TLS protocols. I've tried the obvious option of sending a RADIUS Access-Request containing an EAP-Message TLV with code EAP-Request, type EAP-TLS or EAP-TTLS, but get no response from the server. It replies to other random requests with the expected Access-Reject, so it's responding to requests, just not the TLS ones. All the example message flows I can find, e.g. in RFC 3579, have three parties involved, the client, a NAS, and the RADIUS server, so the client ends up sending an EAP-Response to the NAS rather than anything to the RADIUS server. Does anyone know what I need to send from the client directly to the FreeRADIUS server to trigger the EAP-TLS/TTLS process? I'm looking for something like RADIUS code, EAP code, and EAP type, along with any other RADIUS and EAP TLVs that may be required.
On Nov 6, 2018, at 4:24 AM, Joe Garcia <joe27256@gmail.com> wrote:
I'm working with an embedded device that needs to authenticate to a FreeRADIUS server using EAP-TLS or EAP-TTLS. I don't control the FreeRADIUS server (this means I can't provide debug output, sorry), I just need to authenticate to it from the device, with the server configured to talk EAP-TLS/EAP-TTLS. The device runs custom software that talks RADIUS, EAP, and TLS, but no matter what I try, I can't find the right combination of messages to get the server to negotiate one of the two TLS protocols.
The server needs to be configured to *accept* and *negotiate* EAP-TLS. If you don't control the server and can't get it's debug output, then you should configure your *own* FreeRADIUS server. Which you can then control and get debug output for.
I've tried the obvious option of sending a RADIUS Access-Request containing an EAP-Message TLV with code EAP-Request, type EAP-TLS or EAP-TTLS, but get no response from the server.
That's not how EAP works. The client has to start with an EAP-Identity. Maybe the admin configured the server to ignore packets that contain EAP. The default configuration does *not* do this. The default configuration enables nearly all EAP methods. And the default configuration will send an Access-Reject for broken EAP negotiations. Complain to the admin that they've broken their RADIUS server. And after you've installed FreeRADIUS yourself on a test system, you can instruct him on how to create a working configuration: And, run "eapol_test" yourself to see how EAP is supposed to work. All the information you need is public. There isn't really any need to read the RFCs. For running eapol_test, see my web site: http://deployingradius.com/ There is detailed documentation.
It replies to other random requests with the expected Access-Reject, so it's responding to requests, just not the TLS ones. All the example message flows I can find, e.g. in RFC 3579, have three parties involved, the client, a NAS, and the RADIUS server, so the client ends up sending an EAP-Response to the NAS rather than anything to the RADIUS server.
That's how EAP works, yes.
Does anyone know what I need to send from the client directly to the FreeRADIUS server to trigger the EAP-TLS/TTLS process? I'm looking for something like RADIUS code, EAP code, and EAP type, along with any other RADIUS and EAP TLVs that may be required.
Send an EAP-Message containing an EAP-Identity. That starts EAP. The server SHOULD respond with an Access-Challenge containing an EAP-Message. That EAP-Message essentially says "Hi! Let's do TTLS!" And the process continues from there. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
If you don't control the server and can't get it's debug output, then you should configure your *own* FreeRADIUS server. Which you can then control and get debug output for.
It's a bit more complex than that, the embedded device(s) and server are on an isolated network and talk DNP3 (a SCADA protocol), so they can't easily be redirected to a standard FreeRADIUS server we set up. Without getting into too much boring details, I'm trying to resolve a case of two parties pointing fingers at the other side for doing things wrong, while operating mostly blindfolded...
Send an EAP-Message containing an EAP-Identity. That starts EAP. The server SHOULD respond with an Access-Challenge containing an EAP-Message. That EAP-Message essentially says "Hi! Let's do TTLS!"
Ah, thanks, that gives me something to start with. JG. On Wed, 7 Nov 2018 at 01:49, Alan DeKok <aland@deployingradius.com> wrote:
On Nov 6, 2018, at 4:24 AM, Joe Garcia <joe27256@gmail.com> wrote:
I'm working with an embedded device that needs to authenticate to a FreeRADIUS server using EAP-TLS or EAP-TTLS. I don't control the FreeRADIUS server (this means I can't provide debug output, sorry), I just need to authenticate to it from the device, with the server configured to talk EAP-TLS/EAP-TTLS. The device runs custom software that talks RADIUS, EAP, and TLS, but no matter what I try, I can't find the right combination of messages to get the server to negotiate one of the two TLS protocols.
The server needs to be configured to *accept* and *negotiate* EAP-TLS.
If you don't control the server and can't get it's debug output, then you should configure your *own* FreeRADIUS server. Which you can then control and get debug output for.
I've tried the obvious option of sending a RADIUS Access-Request containing an EAP-Message TLV with code EAP-Request, type EAP-TLS or EAP-TTLS, but get no response from the server.
That's not how EAP works. The client has to start with an EAP-Identity.
Maybe the admin configured the server to ignore packets that contain EAP. The default configuration does *not* do this. The default configuration enables nearly all EAP methods. And the default configuration will send an Access-Reject for broken EAP negotiations.
Complain to the admin that they've broken their RADIUS server. And after you've installed FreeRADIUS yourself on a test system, you can instruct him on how to create a working configuration:
And, run "eapol_test" yourself to see how EAP is supposed to work. All the information you need is public. There isn't really any need to read the RFCs.
For running eapol_test, see my web site: http://deployingradius.com/ There is detailed documentation.
It replies to other random requests with the expected Access-Reject, so it's responding to requests, just not the TLS ones. All the example message flows I can find, e.g. in RFC 3579, have three parties involved, the client, a NAS, and the RADIUS server, so the client ends up sending an EAP-Response to the NAS rather than anything to the RADIUS server.
That's how EAP works, yes.
Does anyone know what I need to send from the client directly to the FreeRADIUS server to trigger the EAP-TLS/TTLS process? I'm looking for something like RADIUS code, EAP code, and EAP type, along with any other RADIUS and EAP TLVs that may be required.
Send an EAP-Message containing an EAP-Identity. That starts EAP. The server SHOULD respond with an Access-Challenge containing an EAP-Message. That EAP-Message essentially says "Hi! Let's do TTLS!"
And the process continues from there.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 7, 2018, at 1:54 AM, Joe Garcia <joe27256@gmail.com> wrote:
Alan DeKok <aland@deployingradius.com> wrote:
If you don't control the server and can't get it's debug output, then you should configure your *own* FreeRADIUS server. Which you can then control and get debug output for.
It's a bit more complex than that,
Not on the RADIUS side. If you're being asked to send packets to a RADIUS server, then you can: a) use espoo_test to test EAP over RADIUS to their RADIUS server b) set up your own RADIUS server to accept RADIUS packets from any RADIUS client you control Between those two options, you should be able to figure out where in the EAP / RADIUS stack the problem lies.
the embedded device(s) and server are on an isolated network and talk DNP3 (a SCADA protocol), so they can't easily be redirected to a standard FreeRADIUS server we set up.
Something needs to send RADIUS packets to the RADIUS server. This isn't difficult. If something is doing EAP, then the EAP packets need to be received by an EAP peer, encapsulated into RADIUS, and then sent to the RADIUS server.
Without getting into too much boring details, I'm trying to resolve a case of two parties pointing fingers at the other side for doing things wrong, while operating mostly blindfolded...
The components and their function can be described in 2-3 sentences, as above. It really is that simple. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
All the example message flows I can find, e.g. in RFC 3579, have three parties involved, the client, a NAS, and the RADIUS server, so the client ends up sending an EAP-Response to the NAS rather than anything to the RADIUS server.
That's how EAP works, yes.
In that case are we being asked to do something that's not possible, i.e. having the client/supplicant talk directly to the RADIUS server without a NAS involved? That would also explain why we're having problems with it.
Send an EAP-Message containing an EAP-Identity. That starts EAP. The server SHOULD respond with an Access-Challenge containing an EAP-Message. That EAP-Message essentially says "Hi! Let's do TTLS!"
I've tried that, and got no resonse from the server... checking RFC 3748, the EAP-Identity is sent by the authenticator, not the client/supplicant: The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. Then RFC 5281 says: However, prior to beginning the EAP- TTLS authentication, the client will typically issue an EAP- Response/Identity packet as part of the EAP protocol but that's the three-party version again since the client can't begin its communication with a Response. This sorta reinforces my suspicion (see above) that we're being asked to implement something that may not be possible? JG.
On Nov 7, 2018, at 7:32 AM, Joe Garcia <joe27256@gmail.com> wrote:
In that case are we being asked to do something that's not possible, i.e. having the client/supplicant talk directly to the RADIUS server without a NAS involved? That would also explain why we're having problems with it.
Yes. A RADIUS server accepts RADIUS packets from a RADIUS client. You can't send raw EAP to a RADIUS server and expect it to work.
Send an EAP-Message containing an EAP-Identity. That starts EAP. The server SHOULD respond with an Access-Challenge containing an EAP-Message. That EAP-Message essentially says "Hi! Let's do TTLS!"
I've tried that, and got no resonse from the server...
Then either you didn't send the right thing, or their RADIUS server is configured to discard all messages containing EAP, or their RADIUS server isn't configured to accept RADIUS packets from your IP address. You *can* run eapol_test yourself, as I suggested in my previous reply. That will tell you if the RADIUS server works at all.
This sorta reinforces my suspicion (see above) that we're being asked to implement something that may not be possible?
Yes. Alan DeKok.
Hello Everyone. I'm using FreeRadius 3-3.0.17_2 and I want to pick an IP from Pool to a user who uses Fixed IP and tries to connect with wrong password. I tried to put this set in my default file and Fixed IP always overrides the pool IP. Auth-Type MS-CHAP { mschap { reject = 1 } if(reject) { update control { Pool-Name := "mkt_pool" } update reply { Mikrotik-Rate-Limit := "300K/2M 600K/2200K 450K/1500K 10/10" } ok } } Some hint? Thanks Aurélio
On Nov 6, 2018, at 11:06 AM, Aurélio de Souza Ribeiro Neto <netolistas@mpc.com.br> wrote:
I'm using FreeRadius 3-3.0.17_2 and I want to pick an IP from Pool to a user who uses Fixed IP and tries to connect with wrong password.
That only works in some cases.
I tried to put this set in my default file and Fixed IP always overrides the pool IP.
Auth-Type MS-CHAP { mschap {
It probably won't work for MS-CHAP. The users system will verify the servers response to see if the server knows the password. If the response isn't correct, the system will drop the connection.
reject = 1 }
if(reject) {
update control { Pool-Name := "mkt_pool" }
update reply { Mikrotik-Rate-Limit := "300K/2M 600K/2200K 450K/1500K 10/10" }
ok }
}
Some hint?
Is anything going wrong? Do you have debug output? What do you expect it to do? What actually happens? Alan DeKok.
Hello Alan, It's not going wrong. I have some users with fixed IPs, but when user try to connect with wrong Password I want that user to use an IP from a determined IPPOOL and not your fixed IP, because using right or wrong password he got Internet. As you always told, the FR is doing the right thing. I just want to do this change. Thank you Aurélio Em 09/11/2018 16:50, Alan DeKok escreveu:
On Nov 6, 2018, at 11:06 AM, Aurélio de Souza Ribeiro Neto <netolistas@mpc.com.br> wrote:
I'm using FreeRadius 3-3.0.17_2 and I want to pick an IP from Pool to a user who uses Fixed IP and tries to connect with wrong password.
That only works in some cases.
I tried to put this set in my default file and Fixed IP always overrides the pool IP.
Auth-Type MS-CHAP { mschap {
It probably won't work for MS-CHAP. The users system will verify the servers response to see if the server knows the password. If the response isn't correct, the system will drop the connection.
reject = 1 }
if(reject) {
update control { Pool-Name := "mkt_pool" }
update reply { Mikrotik-Rate-Limit := "300K/2M 600K/2200K 450K/1500K 10/10" }
ok }
}
Some hint?
Is anything going wrong? Do you have debug output? What do you expect it to do? What actually happens?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 12, 2018, at 11:54 AM, Aurélio de Souza Ribeiro Neto <netolistas@mpc.com.br> wrote:
It's not going wrong.
It's not doing what you want, is it?
I have some users with fixed IPs, but when user try to connect with wrong Password I want that user to use an IP from a determined IPPOOL and not your fixed IP, because using right or wrong password he got Internet.
OK
As you always told, the FR is doing the right thing. I just want to do this change.
Then configure the ippool in the "post-auth" section. And, as I said, this won't work for MS-CHAP. Alan DeKok.
participants (3)
-
Alan DeKok -
Aurélio de Souza Ribeiro Neto -
Joe Garcia