Hi experts, this question is a bit related with one i did last week about EAP-start support. Now is a slightly different use case: I have no expertise with freeradius and do not know how flexible Freeradius 3 may be to customize an authentication policy flow. The use case i am interested in is: Freeradius initiates a EAP Identity Request procedure when it receives and EAP-response message containing just only an EAP Identity AVP. (or if a bit more specific approach might be possible, just only when the provided EAP-identity is not known) The rational behind: Some VPN server(s) do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2). However, the server sends to Radius server an EAP-response type Identity AVP, which is filled with the IKE-ID conveyed by the end customer. Some VPN clients include the EAP user as IKE-ID and all works normally, but some others not, and typically include as IKE-ID the IP address of the supplicant (i.e. windows 10, MAC OS native vpn clients), which is unknown for the radius/db server. I would appreciate your feedback, and, if feasible, some guiding or hints about how to get that policy implemented. Kind regards, Javier
On May 5, 2020, at 12:08 PM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hi experts, this question is a bit related with one i did last week about EAP-start support. Now is a slightly different use case: I have no expertise with freeradius and do not know how flexible Freeradius 3 may be to customize an authentication policy flow. The use case i am interested in is: Freeradius initiates a EAP Identity Request procedure when it receives and EAP-response message containing just only an EAP Identity AVP. (or if a bit more specific approach might be possible, just only when the provided EAP-identity is not known)
What is an "unknown" EAP-Identity? In general, it's impossible to play games with packet state machines. The devices implement particular state machines. If you try to do something special / different, it generally won't work.
The rational behind:
Some VPN server(s) do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2). However, the server sends to Radius server an EAP-response type Identity AVP, which is filled with the IKE-ID conveyed by the end customer. Some VPN clients include the EAP user as IKE-ID and all works normally, but some others not, and typically include as IKE-ID the IP address of the supplicant (i.e. windows 10, MAC OS native vpn clients), which is unknown for the radius/db server.
You can't ask *again* for a different Identity. Even if you sent an EAP Identity request back, the devices would likely (a) fail EAP entirely, or (b) ignore it, or (c) send back the same identity.
I would appreciate your feedback, and, if feasible, some guiding or hints about how to get that policy implemented.
Ask the vendors to fix their implementations. :( Or, update the FreeRADIUS configuration to do identity checks based on some *other* field. Look in the debug logs to see what's available. Alan DeKok.
Thanks Alan,
What is an "unknown" EAP-Identity?i.e. And ID not matching any provisioned user/account (i.e. the IP address of the user, that may change)
In general, it's impossible to play games with packet state machines. The devices implement particular state machines. If you try to do something special / different, it generally won't work. That is way I asked about, I do not know freeradius capabilities. You can't ask *again* for a different Identity. Even if you sent an EAP Identity request back, the devices would likely (a) fail EAP entirely, or (b) ignore it, or (c) send back the same identity.
That is what i am interested in, I do not think the device should ignore EAP Identity (no RFC compliant), no much difference for the device if it is the VPN server or the Radius server initiating the EAP-Identity Request.
Ask the vendors to fix their implementations. :(
Not feasible. Not sure if something is wrong in fact, very unusual might be.
Or, update the FreeRADIUS configuration to do identity checks based on some *other* field. Look in the debug logs to see what's available.
Not sure what you mean, a different attribute in the initial Radius message from the VPN server? No one has significance neither may be correlated with any user information available in the server. Thanks for the feedback Alan, from your words I assume there is no option with Freeradius for this use-case. Kind regards, Javier En martes, 5 de mayo de 2020 18:34:08 CEST, Alan DeKok <aland@deployingradius.com> escribió: On May 5, 2020, at 12:08 PM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hi experts, this question is a bit related with one i did last week about EAP-start support. Now is a slightly different use case: I have no expertise with freeradius and do not know how flexible Freeradius 3 may be to customize an authentication policy flow. The use case i am interested in is: Freeradius initiates a EAP Identity Request procedure when it receives and EAP-response message containing just only an EAP Identity AVP. (or if a bit more specific approach might be possible, just only when the provided EAP-identity is not known)
What is an "unknown" EAP-Identity? In general, it's impossible to play games with packet state machines. The devices implement particular state machines. If you try to do something special / different, it generally won't work.
The rational behind:
Some VPN server(s) do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2). However, the server sends to Radius server an EAP-response type Identity AVP, which is filled with the IKE-ID conveyed by the end customer. Some VPN clients include the EAP user as IKE-ID and all works normally, but some others not, and typically include as IKE-ID the IP address of the supplicant (i.e. windows 10, MAC OS native vpn clients), which is unknown for the radius/db server.
You can't ask *again* for a different Identity. Even if you sent an EAP Identity request back, the devices would likely (a) fail EAP entirely, or (b) ignore it, or (c) send back the same identity.
I would appreciate your feedback, and, if feasible, some guiding or hints about how to get that policy implemented.
Ask the vendors to fix their implementations. :( Or, update the FreeRADIUS configuration to do identity checks based on some *other* field. Look in the debug logs to see what's available. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 5, 2020, at 12:55 PM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:t may change)
In general, it's impossible to play games with packet state machines. The devices implement particular state machines. If you try to do something special / different, it generally won't work. That is way I asked about, I do not know freeradius capabilities.
You misunderstood me. This isn't a limitation of FreeRADIUS. It's a limitation of the protocol design, specifications, and *every* implementation. You can't just invent packet flows and expect them to do what you want. Protocols simply don't work that way,
You can't ask *again* for a different Identity. Even if you sent an EAP Identity request back, the devices would likely (a) fail EAP entirely, or (b) ignore it, or (c) send back the same identity.
That is what i am interested in, I do not think the device should ignore EAP Identity (no RFC compliant), no much difference for the device if it is the VPN server or the Radius server initiating the EAP-Identity Request.
Your opinion doesn't matter. Microsoft and Apple have implemented *something*. And that something follows the specs. It doesn't follow your custom requirements, 15 years later. You can't complain that a system isn't "RFC compliant" when it sends an EAP-Identity, and ignores an EAP-Identity-Request in the response. This packet flow is *not* intended by the protocol authors, and is likely also not implemented by Microsoft and Apple. Your idea was that if you got a "bad" EAP Identity, you could somehow request a "good" one. Again, protocols simply don't work that way. What you want is impossible. For reasons I explained above. I suggest understanding those reasons, instead of insisting that Microsoft and Apple do what you want them to do. It just won't happen.
Or, update the FreeRADIUS configuration to do identity checks based on some *other* field. Look in the debug logs to see what's available.
Not sure what you mean, a different attribute in the initial Radius message from the VPN server? No one has significance neither may be correlated with any user information available in the server.
Yes, I mean look at the RADIUS packets. It is likely that one has significance. Or, there's something else in the EAP messages which allows the server to determine the users identity. VPN servers clearly work with Microsoft and Apple clients. Therefore, it must be possible to authenticate them.
Thanks for the feedback Alan, from your words I assume there is no option with Freeradius for this use-case.
That is entirely NOT what I said. This isn't a difficult message to get across. When I said that the OTHER END likely won't do what you want, you should NOT conclude that the problem is FreeRADIUS. Alan DeKok.
Hi Alan, Just to do not mislead others that might be interested in something similar. Very interesting your speech but nothing to do with the real thing. I have the setup working with a different AAA solution in the market, there is zero problems for the windows VPN clients to work when Radius send the identity-Request. It definitely works perfectly. I have neither ideas nor opinions about EAP. asking for the EAP-identity it is quite normal for several uses-cases and its is quite clear at the RFCs. For different reasons, I needed to asses the possibility of this use-case with Freeradius, that was all. Freeradius is not a problem at all. I like it, I was just asking about the integration with this use-case and asking for advice. Kind regards, Javier En martes, 5 de mayo de 2020 19:10:39 CEST, Alan DeKok <aland@deployingradius.com> escribió: On May 5, 2020, at 12:55 PM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:t may change)
In general, it's impossible to play games with packet state machines. The devices implement particular state machines. If you try to do something special / different, it generally won't work. That is way I asked about, I do not know freeradius capabilities.
You misunderstood me. This isn't a limitation of FreeRADIUS. It's a limitation of the protocol design, specifications, and *every* implementation. You can't just invent packet flows and expect them to do what you want. Protocols simply don't work that way,
You can't ask *again* for a different Identity. Even if you sent an EAP Identity request back, the devices would likely (a) fail EAP entirely, or (b) ignore it, or (c) send back the same identity.
That is what i am interested in, I do not think the device should ignore EAP Identity (no RFC compliant), no much difference for the device if it is the VPN server or the Radius server initiating the EAP-Identity Request.
Your opinion doesn't matter. Microsoft and Apple have implemented *something*. And that something follows the specs. It doesn't follow your custom requirements, 15 years later. You can't complain that a system isn't "RFC compliant" when it sends an EAP-Identity, and ignores an EAP-Identity-Request in the response. This packet flow is *not* intended by the protocol authors, and is likely also not implemented by Microsoft and Apple. Your idea was that if you got a "bad" EAP Identity, you could somehow request a "good" one. Again, protocols simply don't work that way. What you want is impossible. For reasons I explained above. I suggest understanding those reasons, instead of insisting that Microsoft and Apple do what you want them to do. It just won't happen.
Or, update the FreeRADIUS configuration to do identity checks based on some *other* field. Look in the debug logs to see what's available.
Not sure what you mean, a different attribute in the initial Radius message from the VPN server? No one has significance neither may be correlated with any user information available in the server.
Yes, I mean look at the RADIUS packets. It is likely that one has significance. Or, there's something else in the EAP messages which allows the server to determine the users identity. VPN servers clearly work with Microsoft and Apple clients. Therefore, it must be possible to authenticate them.
Thanks for the feedback Alan, from your words I assume there is no option with Freeradius for this use-case.
That is entirely NOT what I said. This isn't a difficult message to get across. When I said that the OTHER END likely won't do what you want, you should NOT conclude that the problem is FreeRADIUS. Alan DeKok.
On May 6, 2020, at 5:20 AM, JAVIER SANDOVAL <javier_sandoval_ldc@yahoo.es> wrote:
Very interesting your speech but nothing to do with the real thing.
This is fundamentally a communication problem. You're not saying what you're doing, and you're misunderstanding what I say. When I say "the other end won't do what you want", your conclusion should *not* be "FreeRADIUS can't do it". That's not what I said. Such a response is not appropriate.
I have the setup working with a different AAA solution in the market, there is zero problems for the windows VPN clients to work when Radius send the identity-Request. It definitely works perfectly.
Post PCAP files.
I have neither ideas nor opinions about EAP.
That's clearly not true. I suggest telling the truth.
asking for the EAP-identity it is quite normal for several uses-cases and its is quite clear at the RFCs.
Will the other end *change* it's identity response as you were implying? Or, send back the same response as I suggested? The RFCs absolutely do not say "Oh, if you ask *enough*, then the other end will send you the *real* identity you want".
For different reasons, I needed to asses the possibility of this use-case with Freeradius, that was all.
Freeradius is not a problem at all. I like it, I was just asking about the integration with this use-case and asking for advice.
FreeRADIUS can do just about anything. You *can* make FreeRADIUS do whatever you want, including sending EAP-Identity requests. Alan DeKok.
Hi, it is clear a communication problem. I have it working, Believe it. I guess the problem is you think end customer EAP Identity need to change at some time for this use case, but it doesn´t. I likely explain badly the use-case. It is not the case, you have two elements. the VPN server telling initially to the Radius server one EAP-identity that it derived from IKE-ID (as the VPN server does not explicitly ask for the EAP-Identity), and the end customer telling the Radius server its real EAP-Identity after requested by Radius. I am happy to know I might finally get sending EAP-Identity Request from Freeradius for this case. That was part of my initial question. Kind regards, Javier En miércoles, 6 de mayo de 2020 13:56:06 CEST, Alan DeKok <aland@deployingradius.com> escribió: On May 6, 2020, at 5:20 AM, JAVIER SANDOVAL <javier_sandoval_ldc@yahoo.es> wrote:
Very interesting your speech but nothing to do with the real thing.
This is fundamentally a communication problem. You're not saying what you're doing, and you're misunderstanding what I say. When I say "the other end won't do what you want", your conclusion should *not* be "FreeRADIUS can't do it". That's not what I said. Such a response is not appropriate.
I have the setup working with a different AAA solution in the market, there is zero problems for the windows VPN clients to work when Radius send the identity-Request. It definitely works perfectly.
Post PCAP files.
I have neither ideas nor opinions about EAP.
That's clearly not true. I suggest telling the truth.
asking for the EAP-identity it is quite normal for several uses-cases and its is quite clear at the RFCs.
Will the other end *change* it's identity response as you were implying? Or, send back the same response as I suggested? The RFCs absolutely do not say "Oh, if you ask *enough*, then the other end will send you the *real* identity you want".
For different reasons, I needed to asses the possibility of this use-case with Freeradius, that was all.
Freeradius is not a problem at all. I like it, I was just asking about the integration with this use-case and asking for advice.
FreeRADIUS can do just about anything. You *can* make FreeRADIUS do whatever you want, including sending EAP-Identity requests. Alan DeKok.
On May 6, 2020, at 8:30 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I have it working, Believe it.
PCAP files?
I guess the problem is you think end customer EAP Identity need to change at some time for this use case, but it doesn´t. I likely explain badly the use-case.
So the EAP Identity doesn't change.
It is not the case, you have two elements. the VPN server telling initially to the Radius server one EAP-identity that it derived from IKE-ID (as the VPN server does not explicitly ask for the EAP-Identity), and the end customer telling the Radius server its real EAP-Identity after requested by Radius.
So the EAP Identity does change. <sigh> Alan DeKok.
participants (2)
-
Alan DeKok -
JAVIER SANDOVAL