EAP Inner/Outer attributes matching! (REPOST) - Avoid identity spoofing in EAP authentications!!!
Sorry for the repost but this problems are forcing-me to leave our FreeRADIUS open to stealing of identity privileges ... PB I'm trying to instruct our freeradius to check some inconsistences PB between inner and outer parameters involved in EAP-TTLS and EAP-PEAP PB authentication of wireless users. PB PB If the return attributes are based in outer identity the system can be PB fooled by using a valid inner identity and obtaining privileges of PB another user (sent as outer identity). PB If the return attributes are based in inner identity, because not all PB the states of EAP authentication involves inner phase, only in the PB phases that involves inner EAP the correct attributes are returned and PB as an example, the user isn't correctly mapped in his correct VLAN. PB PB How can I validate if the same Realm is used in inner and outer PB User-Name ? PB How can I pass variables (attributes) between inner and outer phases ? PB How can I maintain some context of the authentications in progress so PB that I can sent the correct parameters in phases that didn't involve PB inner auth and I can't trust in the outer identity ? TIA. -- Best regards, PedroRibeiro mailto:[EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Inner/Outer attributes matching! (REPOST) - Avoid identity spoofing in EAP authentications!!!
See body of message below for responses: -- Original Message -- From: PedroRibeiro (B) [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Thu, 22 Jul 2004 10:34:57 +0100 Sorry for the repost but this problems are forcing-me to leave our FreeRADIUS open to stealing of identity privileges ... PB I'm trying to instruct our freeradius to check some inconsistences PB between inner and outer parameters involved in EAP-TTLS and EAP-PEAP PB authentication of wireless users. PB PB If the return attributes are based in outer identity the system can be PB fooled by using a valid inner identity and obtaining privileges of PB another user (sent as outer identity). Yep... that is the REASON for an encrypted inner pipe to carry the actual attribute information. PB If the return attributes are based in inner identity, because not all PB the states of EAP authentication involves inner phase, only in the PB phases that involves inner EAP the correct attributes are returned and PB as an example, the user isn't correctly mapped in his correct VLAN. PB You would map the user based on one of the inner attributes... PB How can I validate if the same Realm is used in inner and outer PB User-Name ? WHY would you want to! One of the features of EAP/TTLS is the fact you can have an anonymous username and NAS IP in the outer phase (visible phase) thereby hiding the actual client attributes sent through the inner phase (TTLS pipe). Also, NO password information is passed in the outer phase so that information is also obscured as it only passes between the supplicant and Freeradius server in the TTLS pipe. The information carried in the TTLS pipe is encrypted so as to be secure and if using AES encryption is pretty damned hard to break! I would base all of the client checking ONLY on the information contained within the TTLS pipe and just ignore any attributes passed through the outer phase. You could possibly use the fact that the outer phase usually contains a username of anonymous (unless changed in the supplicant to be something else) and use an external program to check for the proper bogus information in the outer phase - this might be a method to detect possible hack attempts to gain access to the wireless network if the attacker is attempting to guess a username and sending it in the outer phase instead of the username you have assigned to the outer phase in the supplicate on the client machine... PB How can I pass variables (attributes) between inner and outer phases ? Why would you want to? PB How can I maintain some context of the authentications in progress so PB that I can sent the correct parameters in phases that didn't involve PB inner auth and I can't trust in the outer identity ? Sounds like you are making this harder than it needs to be (IMHO)... If the client information in the inner phase does not match up properly just REJECT the connection! Of course this is my own opinion... YMMV gm... TIA. -- Best regards, PedroRibeiro mailto:[EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html --- [This E-mail scanned for viruses by Declude Ant-Virus Scanner] Sent via the KillerWebMail system at mail.brev.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[2]: EAP Inner/Outer attributes matching! (REPOST) - Avoid identity spoofing in EAP authentications!!!
Let-me try to explain better my problem ... Here goes two message lists I've seen authenticating users: ### EAP-TTLS (SecureW2 V2.1.0) with PAP rad_recv: Access-Request packet from host 10.2.64.101:21645, id=35, length=214 Sending Access-Challenge of id 35 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=36, length=206 Sending Access-Challenge of id 36 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=37, length=260 Sending Access-Challenge of id 37 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=38, length=206 Sending Access-Challenge of id 38 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=39, length=206 Sending Access-Challenge of id 39 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=40, length=530 Sending Access-Challenge of id 40 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=41, length=295 Sending Access-Accept of id 41 to 10.2.64.101:21645 -- Only this message contains the attributes returned from Inner auth. ### EAP-PEAP with MSCHAPv2 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=47, length=212 Sending Access-Challenge of id 47 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=48, length=311 Sending Access-Challenge of id 48 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=49, length=205 Sending Access-Challenge of id 49 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=50, length=205 Sending Access-Challenge of id 50 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=51, length=521 Sending Access-Challenge of id 51 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=52, length=205 Sending Access-Challenge of id 52 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=53, length=253 Sending Access-Challenge of id 53 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=54, length=307 Sending Access-Challenge of id 54 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=55, length=228 Sending Access-Challenge of id 55 to 10.2.64.101:21645 -- Only this message contains the attributes returned from Inner auth. rad_recv: Access-Request packet from host 10.2.64.101:21645, id=56, length=237 Sending Access-Accept of id 56 to 10.2.64.101:21645 If I return the VLAN attributes based in the Inner identity, PEAP users only get the correct VLAN from time ... (most of the times they stay in the default VLAN assigned to the SSID), probably because the last message received by the AccessPoint doesn't carry VLAN attributes. If I return the VLAN attributes based in the Outer identity, because the Outer user is most of the times [EMAIL PROTECTED] I can't find the correct VLAN for the user and I'm vulnerable to identity spoofing if users send a valid Outer identity belonging to someone else with different VLAN. TIA. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
