Hi, I got a freeradius configured to handle LEAP authentication. it works with a Cisco AP Cisco Airnet 1100: client 10.0.0.1 { secret = secret shortname = apcisco nastype = cisco } But it fail for linksys WRT54GS: client 192.168.1.1 { secret = secret shortname = linksys nastype = cisco } I tried different nastype : With other or nastype commented, nothing happen after identity frames. With cisco nastype, LEAP didn't finish, AP does not send the last frame to respond to supplicant challenge. Is there a specific nastype for Linksys ot this AP is bugged ? I tried with another RADIUS (SBR/Windows) with the same comportment. Do you know other AP than cisco ones that permit 802.1X successfully with freeradius ? Cordialement, -- Thierry mailto:freeradius@yar-glah.org
hi i don't want to tell nonsense, but as far as I know, LEAP is not a pure EAP type. the AP has thus to support it. and the WRT54 does not. do not blame the WRT, blame LEAP and its design. and it has nothing to do with 802.1X - standard 802.1X protocols should work with WRT54. ciao artur Thierry wrote:
Hi,
I got a freeradius configured to handle LEAP authentication.
it works with a Cisco AP Cisco Airnet 1100: client 10.0.0.1 { secret = secret shortname = apcisco nastype = cisco }
But it fail for linksys WRT54GS:
client 192.168.1.1 { secret = secret shortname = linksys nastype = cisco }
I tried different nastype : With other or nastype commented, nothing happen after identity frames. With cisco nastype, LEAP didn't finish, AP does not send the last frame to respond to supplicant challenge.
Is there a specific nastype for Linksys ot this AP is bugged ? I tried with another RADIUS (SBR/Windows) with the same comportment.
Do you know other AP than cisco ones that permit 802.1X successfully with freeradius ?
Cordialement,
Hi, I am using FreeRADIUS version 1.0.2 and I am trying to authenticate users using CHAP authentication. Everything works and authentication goes through except that users are authenticated successfully( provided userid and password id correct) irrespective of what is entered for the "shared secret" in the client. Is this a defect? Should'nt the RADIUS server check whether the client is using the correct "shared secret"? Thanks and Regards, -Sayantan.
Hi, Sayantan Bhowmick schrieb:
I am trying to authenticate users using CHAP authentication. (snipp) users are authenticated successfully( provided userid and password id correct) irrespective of what is entered for the "shared secret" in the client. Is this a defect?
IIRC, yes, that means the client is broken.
Should'nt the RADIUS server check whether the client is using the correct "shared secret"?
No, he can't, in general. In authentication, the shared secret is used to protect secret data (e.g. cleartext passwords when doing PAP or MPPE-Keys when doing MS-CHAP). Unless you're using one of the attributes encrypted by means of the shared secret, the server never knows whether or not the client is using the same shared secret. IIRC, the server, however, is kind of "signing" his reply with the secret key, so if that's not the same one that the client has, the client should reject the server's reply as coming from a non-trustworthy server and not give you access. HTH, Stefan
Thank You Alan and Stefan for your replies. So if I understand correctly in case of authentication methods like CHAP the client does NOT SEND ANYTHING SIGNED with the "shared secret" and as such the RADIUS server CANNOT verify whether the client has the proper shared secret. In this case it is the clients job to verify the server's reply. Am I correct? Thanks and Regards, -Sayantan. >>> On Thu, Sep 1, 2005 at 7:49 pm, in message <1125583941.43170c45982c4@modem.webmail.t-online.de>, Stefan.Neis@t-online.de wrote:
Hi,
Sayantan Bhowmick schrieb:
I am trying to authenticate users using CHAP authentication. (snipp) users are authenticated successfully( provided userid and password id correct) irrespective of what is entered for the "shared secret" in the client. Is this a defect?
IIRC, yes, that means the client is broken.
Should'nt the RADIUS server check whether the client is using the correct "shared secret"?
No, he can't, in general. In authentication, the shared secret is used to protect secret data (e.g. cleartext passwords when doing PAP or MPPE- Keys when doing MS- CHAP). Unless you're using one of the attributes encrypted by means of the shared secret, the server never knows whether or not the client is using the same shared secret. IIRC, the server, however, is kind of "signing" his reply with the secret key, so if that's not the same one that the client has, the client should reject the server's reply as coming from a non- trustworthy server and not give you access.
HTH, Stefan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Sayantan Bhowmick" <sbhowmick@novell.com> wrote:
So if I understand correctly in case of authentication methods like CHAP the client does NOT SEND ANYTHING SIGNED with the "shared secret" and as such the RADIUS server CANNOT verify whether the client has the proper shared secret. In this case it is the clients job to verify the server's reply. Am I correct?
Yes. Alan DeKok.
"Sayantan Bhowmick" <sbhowmick@novell.com> wrote:
I am using FreeRADIUS version 1.0.2 and I am trying to authenticate users using CHAP authentication. Everything works and authentication goes through except that users are authenticated successfully( provided userid and password id correct) irrespective of what is entered for the "shared secret" in the client. Is this a defect? Should'nt the RADIUS server check whether the client is using the correct "shared secret"?
For CHAP, it can't. The *client* will see that the response packet isn't signed properly, and will reject it. Alan DeKok.
Sayantan Bhowmick wrote:
Hi, I am using FreeRADIUS version 1.0.2 and I am trying to authenticate users using CHAP authentication. Everything works and authentication goes through except that users are authenticated successfully( provided userid and password id correct) irrespective of what is entered for the "shared secret" in the client. Is this a defect? Should'nt the RADIUS server check whether the client is using the correct "shared secret"?
Thanks and Regards, -Sayantan.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (6)
-
Alan DeKok -
Artur Hecker -
Michael Lecuyer -
Sayantan Bhowmick -
Stefan.Neis＠t-online.de -
Thierry