Checking Reply Attributes (How?)
What syntax should I use to verify if there is some attribute is already
in the reply list ?
Is there any specific syntax to check attributes of type octets ?
Examples of what I wanted to do ...
This way MS-MPPE-Recv-Key isn't found because he is in the reply list,
not in the check list ...
DEFAULT MS-MPPE-Recv-Key =* ''
IPLNet-Message = EAP Key included ...
If the attribute: EAP-Message = 0x030b0004 is in the reply list, how
can I verify if the value matches 0x03??0004 (something
similar to '%{reply:EAP-Message}' 0xff00 == 0x0304 )
TIA.
--
Best regards,
PedroRibeiro mailto:[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[2]: Passing internal attributes between modules
Hello Alan, Good!, can you give-me an example of how to do it ? (I've read doc/aaa.txt, doc/variables.txt and doc/rlm_sql ) All the tests I've done trying to pass information between modules have failed. In which attributes list are they stored ? Is there any way of adding an attribute to the request list ? Thanks. Friday, July 23, 2004, 9:37:36 PM, you wrote: AD PedroRibeiro (B) [EMAIL PROTECTED] wrote: Is there any way of passing values in internal attributes between modules while processing the authorization (set an attribute when process the users file to be used in sql authorization) ? AD Uh, yes. That's how the server works. AD Alan DeKok. AD - AD List info/subscribe/unsubscribe? See AD http://www.freeradius.org/list/users.html -- Best regards, PedroRibeiromailto:[EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Passing internal attributes between modules
Is there any way of passing values in internal attributes between modules while processing the authorization (set an attribute when process the users file to be used in sql authorization) ? TIA. -- Best regards, PedroRibeiro mailto:[EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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[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
EAP Inner/Outer attributes checking
I'm trying to instruct our freeradius to check some inconsistences between inner and outer parameters involved in EAP-TTLS and EAP-PEAP authentication of wireless users. If the return attributes are based in outer identity the system can be fooled by using a valid inner identity and obtaining privileges of another user (sent as outer identity). If the return attributes are based in inner identity, because not all the states of EAP authentication involves inner phase, only in the phases that involves inner EAP the correct attributes are returned and as an example, the user isn't correctly mapped in his correct VLAN. How can I validate if the same Realm is used in inner and outer User-Name ? How can I pass variables (attributes) between inner and outer phases ? How can I maintain some context of the authentications in progress so that I can sent the correct parameters in phases that didn't involve 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
