We do have a question Is there anything in configuration that allows to turn off authentication We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
On 27/05/11 16:16, Lubenski, Zeev [GCS] wrote:
We do have a question
Is there anything in configuration that allows to turn off authentication
We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
No, can't be done. EAP is a challenge/response protocol, and you must send the relevant challenges. In EAP-TTLS, you might be able to just force-accept the inner auth, because that's usually just PAP (no challenge / response). You can't for example do this in PEAP, because the inner protocol (MSCHAP) is also challenge/response.
On Fri, May 27, 2011 at 10:28 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 27/05/11 16:16, Lubenski, Zeev [GCS] wrote:
We do have a question
Is there anything in configuration that allows to turn off authentication
We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
No, can't be done. EAP is a challenge/response protocol, and you must send the relevant challenges.
In EAP-TTLS, you might be able to just force-accept the inner auth, because that's usually just PAP (no challenge / response). You can't for example do this in PEAP, because the inner protocol (MSCHAP) is also challenge/response.
Phil, Zeev asked about EAP-TTLS, and you said "you might be able to just force-accept the inner auth, because that's usually just PAP (no challenge / response)". But before that you also said "No, can't be done. EAP is a challenge/response protocol". Are you perhaps thinking that Zeev wrote EAP-MSCHAP instead of EAP-TTLS? -- Fajar
On 27/05/11 16:41, Fajar A. Nugraha wrote:
Phil, Zeev asked about EAP-TTLS, and you said "you might be able to just force-accept the inner auth, because that's usually just PAP (no challenge / response)". But before that you also said "No, can't be done. EAP is a challenge/response protocol".
Are you perhaps thinking that Zeev wrote EAP-MSCHAP instead of EAP-TTLS?
No. I understood his post just fine. I am differentiating between the outer auth and the inner auth. You cannot just force an "Accept" for EAP-TTLS (the outer auth) You can possibly force an "Accept" for inner auth method, if it's PAP.
Phil I am new to free radius, How can I change authentication type on the server to something simple - like user id/password and than accept always ? Regards Zeev -----Original Message----- From: freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org [mailto:freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Friday, May 27, 2011 10:29 AM To: freeradius-users@lists.freeradius.org Subject: Re: On 27/05/11 16:16, Lubenski, Zeev [GCS] wrote:
We do have a question
Is there anything in configuration that allows to turn off authentication
We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
No, can't be done. EAP is a challenge/response protocol, and you must send the relevant challenges. In EAP-TTLS, you might be able to just force-accept the inner auth, because that's usually just PAP (no challenge / response). You can't for example do this in PEAP, because the inner protocol (MSCHAP) is also challenge/response. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 27/05/11 16:42, Lubenski, Zeev [GCS] wrote:
Phil
I am new to free radius, How can I change authentication type on the server to something simple - like user id/password and than accept always ?
Can you describe your setup in more detail? There are several possible answers.
Can one not "override" the ... not sure what it would be called... Example; if I tell FR to use NTLM_AUTH to authenticate a request against AD, and AD returns a "reject", can I not override the reject with and accept using "update control" or some similar function? G -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Friday, May 27, 2011 10:53 AM To: freeradius-users@lists.freeradius.org Subject: Re: Force "Accept" to authentication On 27/05/11 16:42, Lubenski, Zeev [GCS] wrote:
Phil
I am new to free radius, How can I change authentication type on the server to something simple - like user id/password and than accept always ?
Can you describe your setup in more detail? There are several possible answers. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
On 27/05/11 16:59, Gary Gatten wrote:
Can one not "override" the ... not sure what it would be called... Example; if I tell FR to use NTLM_AUTH to authenticate a request against AD, and AD returns a "reject", can I not override the reject with and accept using "update control" or some similar function?
It depends. If you're using ntlm_auth to do MSCHAP, then no. The MS-CHAPv2 reply adds a final response, that proves to the *client* that the *server* is valid. The authentication flow is as follows: nas -> client: challenge client -> nas: response nas -> radius: challenge, response radius -> nas: final response nas -> client: final response ...the client checks that the final response is valid against the challenge and response, as well as it's own password, using crypto. The protocol is *designed* to stop this kind of interference. Now, a buggy client might ignore the final response, but that is a big security hole - it means you can man-in-the-middle the MSCHAP - and as far as I'm aware, all MSCHAP clients (including EAP-PEAP with EAP-MSCHAP inner, and EAP-TTLS with EAP-MSCHAP inner) check this. You can of course just "accept" PAP requests, so if you're doing EAP-TTLS with PAP inner, you can force accept - but you must do it at the *inner* auth. The outer TTLS still needs to be allowed to flow to completion unhindered.
Phil We have a WiMAX client that supports only EAP-TLS, on our side (long story why) - we support only EAP-TTLS Here is the scenario: Client ----> Server Access Request Server---> Client Challenge with EAP-TTLS Client--> Server - nop EAP TLS Server ---> Client Ok - EAP TLS it is, but this in g=fact can't work (our internal problems) so the authentication fails What we are trying to do is to accept the very first Access Request I am thinking just to set authentication type on the Server as a user id /password and allow any user, so we can answer with accept on very first message Regards Zeev -----Original Message----- From: freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org [mailto:freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Friday, May 27, 2011 10:53 AM To: freeradius-users@lists.freeradius.org Subject: Re: Force "Accept" to authentication On 27/05/11 16:42, Lubenski, Zeev [GCS] wrote:
Phil
I am new to free radius, How can I change authentication type on the server to something simple - like user id/password and than accept always ?
Can you describe your setup in more detail? There are several possible answers. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 27/05/11 17:05, Lubenski, Zeev [GCS] wrote:
Ok - EAP TLS it is, but this in g=fact can't work (our internal problems) so the authentication fails
What we are trying to do is to accept the very first Access Request
Sorry, I don't think that's possible. If the WiMAX client is only capable of EAP-TLS, you must do EAP-TLS. And EAP-TLS requires a complete TLS negotiation and completion. I assume it's impossible for you to enable EAP-TLS for some reason?
I am thinking just to set authentication type on the Server as a user id /password and allow any user, so we can answer with accept on very first message
If you do that, the WiMAX client will basically see this: client: EAP-TLS: TLS client hello server: EAP-Success <no data> ...and the client will assume something has gone wrong, because it was expecting a TLS packet back. This is what I mean when I say you can't interfere with the outer tunnel - it's *designed* that way to be secure and prevent interference. HOWEVER - possibly the WiMAX client is dumb, and will do this: client: EAP-TLS: TLS client hello server: EAP-Success <no data> client: Ok, that's fine If so it's insecure, but it will solve your problem. Try this in sites-enabled/default: authorize { # Put any comparison you like here if (Calling-Station-Id == "the_wimax_mac?") { update control { Auth-Type := Accept } } } ...but I doubt it will work.
Phil Thanks a lot will give it a try Regards Zeev -----Original Message----- From: freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org [mailto:freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Friday, May 27, 2011 11:32 AM To: freeradius-users@lists.freeradius.org Subject: Re: Force "Accept" to authentication On 27/05/11 17:05, Lubenski, Zeev [GCS] wrote:
Ok - EAP TLS it is, but this in g=fact can't work (our internal problems) so the authentication fails
What we are trying to do is to accept the very first Access Request
Sorry, I don't think that's possible. If the WiMAX client is only capable of EAP-TLS, you must do EAP-TLS. And EAP-TLS requires a complete TLS negotiation and completion. I assume it's impossible for you to enable EAP-TLS for some reason?
I am thinking just to set authentication type on the Server as a user id /password and allow any user, so we can answer with accept on very first message
If you do that, the WiMAX client will basically see this: client: EAP-TLS: TLS client hello server: EAP-Success <no data> ...and the client will assume something has gone wrong, because it was expecting a TLS packet back. This is what I mean when I say you can't interfere with the outer tunnel - it's *designed* that way to be secure and prevent interference. HOWEVER - possibly the WiMAX client is dumb, and will do this: client: EAP-TLS: TLS client hello server: EAP-Success <no data> client: Ok, that's fine If so it's insecure, but it will solve your problem. Try this in sites-enabled/default: authorize { # Put any comparison you like here if (Calling-Station-Id == "the_wimax_mac?") { update control { Auth-Type := Accept } } } ...but I doubt it will work. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Lubenski, Zeev [GCS] wrote:
We have a WiMAX client that supports only EAP-TLS, on our side (long story why) - we support only EAP-TTLS
This will not work.
What we are trying to do is to accept the very first Access Request
This is impossible. Alan DeKok.
Our problem that we can't change the state machine on the ASN GW and disable authentication from the client, but we are trying somehow to completely disable it on the AAA (some workaround) -----Original Message----- From: freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org [mailto:freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Friday, May 27, 2011 10:53 AM To: freeradius-users@lists.freeradius.org Subject: Re: Force "Accept" to authentication On 27/05/11 16:42, Lubenski, Zeev [GCS] wrote:
Phil
I am new to free radius, How can I change authentication type on the server to something simple - like user id/password and than accept always ?
Can you describe your setup in more detail? There are several possible answers. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The type of auth is determined by the client / NAS / Supplicant. FR just does what it's told. Hence, you would need to implement changes on the devices requesting auth. G -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Lubenski, Zeev [GCS] Sent: Friday, May 27, 2011 10:42 AM To: FreeRadius users mailing list Subject: RE: Re: Phil I am new to free radius, How can I change authentication type on the server to something simple - like user id/password and than accept always ? Regards Zeev -----Original Message----- From: freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org [mailto:freeradius-users-bounces+zlubensk=lgsinnovations.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Friday, May 27, 2011 10:29 AM To: freeradius-users@lists.freeradius.org Subject: Re: On 27/05/11 16:16, Lubenski, Zeev [GCS] wrote:
We do have a question
Is there anything in configuration that allows to turn off authentication
We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
No, can't be done. EAP is a challenge/response protocol, and you must send the relevant challenges. In EAP-TTLS, you might be able to just force-accept the inner auth, because that's usually just PAP (no challenge / response). You can't for example do this in PEAP, because the inner protocol (MSCHAP) is also challenge/response. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
On Fri, May 27, 2011 at 10:16 PM, Lubenski, Zeev [GCS] <zlubensk@lgsinnovations.com> wrote:
We do have a question
Is there anything in configuration that allows to turn off authentication
We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
Try editing your users file (usually /etc/raddb/users). See http://wiki.freeradius.org/FAQ#wiki-How_do_I_permit_access_to_any_user_regar... -- Fajar
FWIW the link below doesn't work - at leat for me. Grit::GitRuby::Internal::LooseObjectError at /FAQ size mismatch file: loose.rb location: get_raw_object line: 59 -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Fajar A. Nugraha Sent: Friday, May 27, 2011 10:44 AM To: FreeRadius users mailing list Subject: Re: On Fri, May 27, 2011 at 10:16 PM, Lubenski, Zeev [GCS] <zlubensk@lgsinnovations.com> wrote:
We do have a question
Is there anything in configuration that allows to turn off authentication
We are running EAP-TTLS and would like instead of sending challenge on Access send Access accept always. (No authentication in fact)
Try editing your users file (usually /etc/raddb/users). See http://wiki.freeradius.org/FAQ#wiki-How_do_I_permit_access_to_any_user_regar... -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
participants (5)
-
Alan DeKok -
Fajar A. Nugraha -
Gary Gatten -
Lubenski, Zeev [GCS] -
Phil Mayers