PacketFence - BTS - PacketFence
View Issue Details
0001034PacketFenceradiuspublic2010-07-21 13:312012-08-14 09:15
obilodeau 
obilodeau 
lowmajoralways
closedfixed 
 
2.0.02.0.0 
9fc787813f9d6bed73a2b0fcb098227044076c9e
0001034: Our freeradius module is not aware of EAP's success or failure
Any action we make in our radius module will be triggered over 802.1X no matter if EAP is successful or not. This means that an unauthenticated user can insert itself in locationlog, etc. even if he doesn't have the right credentials.

Not critical but let me give you an example where this is a problem:

Auto-registration of successfully authenticated devices. Since we can't tell if EAP was successful or not, we will always auto-register a device trying to do dot1x and in certain setup he could fall-back to MAB and be considered registered! That's bad!
No tags attached.
child of 0001002closed obilodeau Optional auto-registration of authenticated devices 
Issue History
2010-07-21 13:31obilodeauNew Issue
2010-07-21 13:31obilodeauStatusnew => assigned
2010-07-21 13:31obilodeauAssigned To => obilodeau
2010-07-21 13:36obilodeauRelationship addedchild of 0001002
2010-08-25 15:19obilodeauNote Added: 0001631
2010-09-24 18:17obilodeauNote Added: 0001694
2010-09-27 16:13obilodeaumtn revision => 9fc787813f9d6bed73a2b0fcb098227044076c9e
2010-09-27 16:13obilodeauNote Added: 0001697
2010-09-27 16:13obilodeauStatusassigned => resolved
2010-09-27 16:13obilodeauFixed in Version => 1.9.2
2010-09-27 16:13obilodeauResolutionopen => fixed
2010-11-19 14:23obilodeauFixed in Version1.9.2 => trunk
2010-11-19 14:25obilodeauTarget Version1.10.0 => 2.0.0
2010-12-15 11:37obilodeauFixed in Versiontrunk => 2.0.0
2011-01-26 15:42obilodeauStatusresolved => closed
2012-08-14 09:15obilodeauCategoryradius module => radius

Notes
(0001631)
obilodeau   
2010-08-25 15:19   
Reading freeradius' doc/aaa.txt I've come to realize that all our code is not in the correct section and that's why there are a lot of seemingly duplicated requests in some of our setups.

Anyway, I can't make progress without a dot1x enabled lab right now so here are some notes of my progress.

Try moving our code in post-auth {...} and see what happens with dot1x success and dot1 failures.

Try rlm_perl's post_auth() and dump all radius-related hashes:
- %RAD_CHECK Read-only Check items
- %RAD_REQUEST Read-only Attributes from the request
- %RAD_REPLY Read-write Attributes for the reply

Also, for reference: we could have a module for auth failure and a module for auth success and do different stuff based on that.
See http://freeradius.org/radiusd/doc/Post-Auth-Type [^]
(0001694)
obilodeau   
2010-09-24 18:17   
Very good progress on this new request. Using post-auth I'm able to do exactly what's required. I'm even thinking of porting this into the 1.9 branch in our current radius module.
(0001697)
obilodeau   
2010-09-27 16:13   
Change implemented in 1.9 on the SQL module and ported into trunk and the SOAP module.