Peter Stamfest <[EMAIL PROTECTED]> wrote: > One solution would be to base the authorization on the content of the > certificate (its DN or DN parts). > > Is this possible with current sources?
If it's not in the current CVS, I do know there was a patch posted a while back. My "patches" mail folder says: Nov. 26 Michael Griego [Patch] Add CN Checking for EAP-TLS authentication > It seems the current EAP-TLS implementation in freeradius does the > TLS-handshake after the authorization phase (looking at the logs > produced by "radiusd -X" seems to indicate this), which would make > authorization based on certificate content look harder to implement > for me.... True. I've been looking at making more of the EAP module work in the "authorization" phase, but I haven't gotten very far. > On a side note: The very same issue seems to make it impossible to do any > Simultanous-Use restrictions based on certificates. A user could just > install the very same certificate on several machines and configure a > different (allowed) User-Name for 802.1x. It's worse than that. Simultaneous-Use is problematic for *any* EAP method. The AP often doesn't keep track of who's logged on, so checrad doesn't work. It often doesn't supply things like NAS-Port, so radutmp doesn't work. And when using certificates, TTLS and PEAP are problematic. There's an "outer" User-Name, and an "inner" User-Name. Which one do you use? You can send a User-Name back in an Access-Accept, but you need to send the inner one, as the outer is often "anonymous". But if you do that, everyone else on the network can see that inner username... which was previously hidden in a TLS tunnel. It's not nice. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
