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