Freeradius 2.0 - vmps feature, inaccuracies on FreeNAC
Hi, Thanks for taking the time to respond, I understand better, see the answers inline below.. ...
http://lists.cistron.nl/pipermail/freeradius-users/2006- August/056121.html
FreeNAC is announced: "The 'plan' is for the project to move forward to eventually become THE OpenSource Enterprise tool for dynamic VLAN assignment and LAN/WLAN authentication."
Uh... right. FreeRADIUS hasn't been doing that already for nearly a decade? FreeRADIUS is *crushing* Cisco and Microsoft in the AAA space. It's doing LAN & WLAN authentication daily for hundreds of millions of users. There is *nothing* in the WLAN authentication space (open source or otherwise) that competes with FreeRADIUS. I *regularly* here about sites with 10+ million users switching to FreeRADIUS.
I was thinking in a very different way. The idea was not to create any tensions or competition with other OpenSource products. My focus was to offer "LAN Access Control", what many people call "NAC". To me there was no solution for that, from systems management point of view. So I created the DB and GUI around OpenVMPS, added switch/router scanning, integration with other network tools and a GUI. We did not try to replace OpenVMPS, or FreeRadius, but make them easier to use in one specific environment: LAN control. When I said "become THE OpenSource Enterprise tool for dynamic VLAN..", it was a call to ask people to help and work, not a declaration against other tools like Freeradius. I like the idea of setting a goal.
And FreeNAC is going to become "THE" project for LAN & WLAN authentication... by "tying in" FreeRADIUS as a subsidiary project?
Honestly, what reaction did you expect?
It wasn't a provocation, really. I did not think FreeRadius sees itself as a NAC server.
It's one thing to say "we've written a web gui that administers VMPS and RADIUS". It's another thing *entirely* to say that a project funded by a large company is going to "tie in" FreeRADIUS, and become "THE" market leader in the space.
Hang on, I meant to use FreeRadius for the 802.1x, my focus was to add whatever additional DB modules, interfaces, or GUIs were necessary. A pity we didn't discuss this along time ago.. ...
FreeNAC, like some other projects, appears largely to be a way to generate consulting revenue. That isn't a bad thing, as people have to make money. But don't pretend that it's an "open" project because your boss tells you to (1) work on it, and to (2) accept patches from other people.
Actually no, it was first and foremost a GPL project with the aim of publishing the work done so far. I really consider it to be an open project, it was, and still is my first priority to create an OpenSurce GPL project that could live with or without its initial sponsor, Swisscom Innovations. No boss told me to work on it, its been my idea from day 1. The idea of the consulting is to try and get some funding to ensure the long term survival. I did not think of GPL and funding as mutually exclusive, but you do? ....
- "Good luck getting patches added if they conflict with the corporate agenda" The community are free to change FreeNAC themselves, and submit patches,
... which may or may not be accepted.
Is there anyone *other* than a Swisscom employee who has CVS commit access to FreeNAC?
You can have SVN access if you want. Any developer can have it if he takes the time. All I ask is that, like in most projects there is a phase where people get to know each other, communicate, and ensure patches do not create major stability problems.
For similar examples, see ISC, and the third-party patches to Bind and dhcpd. There are patches floating around for features used by many sites. Those patches are tested, widely used, in wide demand, and aren't included in the main distribution. The reasons they're not included aren't nefarious... just reality.
Is the ISC GPL?
In contrast, FreeRADIUS adds features that people need. If a patch works, and enough people say they're using it, the patch goes in. (Modulu some editorial re-writes). This is the way it's worked for almost a decade, and this is the way it will *always* work.
Good. Perhaps you could explain your CVS commit policy, or what we should do differently? ...
if we don't do it fast enough. That is what OpenSource is about. The core team is not closed to Swisscom Innovation people either. I'll welcome anyone with the motivation, skills and time. This is, I repeat, a GPL - OpenSource project.
... started by a company, with the core team being solely company employees.
There are many open source, GPL projects that work that way. But they make it clear they're corporate projects with community input. They don't pretend they're community projects. The ones that try to co-opt community projects encounter hostility from that community.
My intention *is* to create a community with a consulting spinoff, not the other way around. ...
*I* got annoyed. But that's because it was clear that FreeNAC was using *my* work to claim that *they* were the leader in the WLAN authentication space.
That I understand now. As regards WLAN, I only mentioned that as an aim, because its turns out that if you doing LAN access control on wired LAN, its useful if it can do wireless too.
But, at the end, I'd really like to close this misunderstanding and move further. There's no point in arguing or flaming each other as we're both working on closely related opensource project.
I would like to move forward in a productive manner. As such, I've added VMPS functionality to FreeRADIUS. Since it is has more features, is more functional, and is more configurable then the OpenVMPS server in FreeNAC, I expect you to switch to using a real VMPS server in the next release.
The OpenVMPS tool/interface is "real" and has worked well for us. I will download FreeRadius and look at your implementation. ...
In fact, FreeRADIUS was always in our mind, we announced FreeNAC on the "freeradius-user" mailing list in 2006 and we also integrated it. This is natural because the core value of FreeNAC is in at the "policy level", and not in the support of underlying protocols like VMPS or 802.1x.
The announcement was... interesting. The claim to be "THE" project for LAN & WLAN authentication was grandiose from a project and people with *zero* track record.
It was an aim, not a claim.
We've also closely followed the development in the NAC area and contacted other opensource projects (SecureW2, NAC@FHH) for that purpose.
We would enjoy a collaboration that would lead to create _the_ opensource NAC framework.
Really. The original announcement didn't mention the word "collaboration". If it had, it would have been more positive. Instead, it looked a lot like the intent was to put a web front end on FreeRADIUS, and label the result as "FreeNAC". Maybe with a
fine-print
disclaimer of "by the way, it's a corporate project that builds on a decade of community work on FreeRADIUS".
Yes, the original announcement *really* got under my skin. Rather than fight you, I spent a few hours writing code that filled a market demand: a supported and actively maintained VMPS server.
Well it's a pity I didn't know that, that really was not the aim, but I guess the damage is done now.
FreeNAC can do what it wants. When v2.0 is released, FreeRADIUS will be the most widely used VMPS server on the planet. And the best way to get a web GUI for VMPS + RADIUS shipped to 100k sites will be to include it's code in FreeRADIUS.
Alan DeKok.
VMPS is only one part of the problem. Do you want to add a Database, Client Security tools/interfaces, policy engine, interfaces to AntiVirus servers, scanners, Patch servers, and so to FreeRadius? I thought Freeradius concentrates on the authentication protocols, not the network integration aspects? Regards, Sean
VMPS is only one part of the problem. Do you want to add a Database, Client Security tools/interfaces, policy engine, interfaces to AntiVirus servers, scanners, Patch servers, and so to FreeRadius?
Yes. By implementing EAP-TNC.
I thought Freeradius concentrates on the authentication protocols, not the network integration aspects?
Perhaps you could explain, if FreeRadius supported EAP-TNC, why I as a medium/large organisation would possibly want to use FreeNAC? Bearing in mind that (correct me if I'm wrong) FreeNAC consists of: * a database schema * a web editor for said database * a gui editor for said database (bleh) * a freeradius config to authenticate off that database * a patched version of openvmps to query off that database * yet another re-implementation of netdisco (www.netdisco.org) talking to the same database * some helper utilities for pulling info from SMS/Wsus We (for example) already have a network/vlan/switchh/host/router database, SQL schema and SQL servers, web interface to same, device management/discover/polling and helper utilties hooked up to wsus. I'm not saying what FreeNAC is doing is wrong, but it does not help to represent it as something it's not. I would have understood this a lot more: """FreeNAC is a standard database schema, GUI and set of management tools for running access-controlled LAN networks. It uses FreeRadius and OpenVMPS, running against MySQL, to perform its job.""" If you're interested, perhaps I can make some constructive suggestions about ways FreeNAC could offer actual added value to medium/large orgs. All this is, of course, my personal opinion (and I've got to tell you, you've zero chance of selling to us because we don't work that way, but anyway... ;o): * a GPLed, ActiveX / Java / other browser-based endpoint posture assessment client, for use in fallback non-802.1x (walled-garden) mode. * contribute working EAP-TNC to FreeRadius * contribute working PEAPv2 and whatever-the-vista-posture-protocol is called * liase with the FreeRadius SQL developers to come up with the most appropriate SQL schema; ideally (from your PoV) the FreeNAC SQL schema could become the default for new FreeRadius installs. Hope that perspective is useful.
Hi,
If you're interested, perhaps I can make some constructive suggestions about ways FreeNAC could offer actual added value to medium/large orgs. All this is, of course, my personal opinion (and I've got to tell you, you've zero chance of selling to us because we don't work that way, but anyway... ;o):
I would go along with these things. obviously there IS a market for FreeNAC as we continually have questions about the PHP web front end admin tool which people seem to use..... ..but then add the extras in too * integrated billing system * improved ability to print access tickets * add in support for trapeze/cisco/aruba specific extensions and location awareness * SNMP trap support for various edge events (eg physical client disconnect, so close accounting session) alan
Ok, as my email adress doesn't show, I'm also working wit Sean (yes, for the "blue giant"). I'll first answer some points raised by alan : - VMPS in FreeRadius was a surprise and is positive. - sure, you can get part of the funding (see later). On 10/07/07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
VMPS is only one part of the problem. Do you want to add a Database, Client Security tools/interfaces, policy engine, interfaces to AntiVirus servers, scanners, Patch servers, and so to FreeRadius?
Yes. By implementing EAP-TNC.
I thought Freeradius concentrates on the authentication protocols, not the network integration aspects?
Perhaps you could explain, if FreeRadius supported EAP-TNC, why I as a medium/large organisation would possibly want to use FreeNAC? Bearing in mind that (correct me if I'm wrong) FreeNAC consists of:
* a database schema * a web editor for said database * a gui editor for said database (bleh) * a freeradius config to authenticate off that database * a patched version of openvmps to query off that database * yet another re-implementation of netdisco (www.netdisco.org) talking to the same database * some helper utilities for pulling info from SMS/Wsus
More or less ok. We (for example) already have a network/vlan/switchh/host/router
database, SQL schema and SQL servers, web interface to same, device management/discover/polling and helper utilties hooked up to wsus.
Ok, so that's very similar. We also wanted that, didn't find any tools that met our requirements, implemented ours and "went out" with it. I'm not saying what FreeNAC is doing is wrong, but it does not help to
represent it as something it's not. I would have understood this a lot more:
"""FreeNAC is a standard database schema, GUI and set of management tools for running access-controlled LAN networks. It uses FreeRadius and OpenVMPS, running against MySQL, to perform its job."""
well, the website now shows " FreeNAC is an OpenSource solution for LAN access control and dynamic Vlan management") first sentence is basically the same when replacing "a standard database schema, GUI and set of management tools" by "solution" - which is simpler. I guess we should highlight the "based on" aspect by putting it on the main page (cf packetfence). Would you find that OK ? If you're interested, perhaps I can make some constructive suggestions
about ways FreeNAC could offer actual added value to medium/large orgs. All this is, of course, my personal opinion (and I've got to tell you, you've zero chance of selling to us because we don't work that way, but anyway... ;o):
thanks a lot * a GPLed, ActiveX / Java / other browser-based endpoint posture
assessment client, for use in fallback non-802.1x (walled-garden) mode.
right. but I guess it should come after a 802.1x and a VPN client ... and those still don't exist * contribute working EAP-TNC to FreeRadius That's something already written by the TNC@FHH projects. Code is available here http://tnc.inform.fh-hannover.de/wiki/index.php/Download Is there any plan to integrate that in the official release ? * contribute working PEAPv2 and whatever-the-vista-posture-protocol is
called
to precise quickly : Vista posture protocol has been microsoft-standardized as "IF-TNCCS-SOH" (statement of health) - https://www.trustedcomputinggroup.org/specs/TNC/IF-TNCCS-SOH_v1.0_r8.pdf <mixofunconfirmedbits> Concerning those three points, in no particular order - We would really be happy to see the mentionned items implemented (in freeradius for TNC). - We have funding - but not unlimited nor for an undefine time period - Some of it could be assigned to implement those protocols. - Alan, before jumping the gun on that f word, it would be no strings attached (bounty-like, resulting code solely licensed under GPL in freeradius, copyright retained by the author, ...). - Coordination with other related opensource project, especially TNC@FHH. </mixofunconfirmedbits> * liase with the FreeRadius SQL developers to come up with the most
appropriate SQL schema; ideally (from your PoV) the FreeNAC SQL schema could become the default for new FreeRadius installs.
If I understood FreeRadius SQL correctly, the way chosen is a very minimalistic one, with very few formal definition. Therefore, it is also very flexible ... and apart from supporting eventual additionnal fields/functions due to the SOH extension, I have the impression that the DB format could (should) be left to the GUI/extra tools part ? BTW, I've also worked previously on IDS and I tried many tools (nmap, nessus, snmp) and meta-tools (netdisco, ...) to map a network and put that into some DB. So far, I did not found anything convincing that's wy we always end up with some custom database. I'll be happy to compare what we have (freenac db) with your db schema. Hope that perspective is useful. Well, technically, for full NAC, we also miss the "post-connect" aspects (cf packetfence) - but that's another story. But, OTOH, not that much switches understand the "packet of disconnect". A lot, I hope it'll start getting the two highly respectable but sometime emotive leaders on a more constructive mood (yes, I'll be flamed for that, I know, I know) your humble, dago PS : of course, I also have plans for total world domination - but I'll first start to become sean's boss. Then, I can move to mind-controlling hundreds of million of people.
Thomas Dagonnier wrote: ...
well, the website now shows " FreeNAC is an OpenSource solution for LAN access control and dynamic Vlan management")
<shrug> RADIUS been doing VLAN management for years. Maybe that's news, I don't know.
I guess we should highlight the "based on" aspect by putting it on the main page (cf packetfence). Would you find that OK ?
It would be politer than burying it elsewhere.
right. but I guess it should come after a 802.1x and a VPN client ... and those still don't exist
wpa_supplicant, xsupplicant, and SecureW2 are well-known GPL'd 802.1x clients. I've been in contact with those developers for years. There's already work on an open source 802.1x client with additional (i.e. NAC) features. Search the net.
That's something already written by the TNC@FHH projects. Code is available here http://tnc.inform.fh-hannover.de/wiki/index.php/Download
I was in contact with them when they first wrote the code, quite a while ago.
Is there any plan to integrate that in the official release ?
Last I checked (quite a whole ago), the code wasn't GPL'd. It looks like it's changed since then. After a quick look, perhaps. The formatting should really follow the FreeRADIUS standard, it has C++ style comments, and some things likely need to be cleaned up. There's also the issue of which license libtnc falls under. On top of that, they haven't requested that it be added to FreeRADIUS.
- Alan, before jumping the gun on that f word,
Perhaps you haven't been following my messages, or the history of FreeRADIUS. A number of features in FreeRADIUS have been funded by various companies. I don't object to funding, and I've never objected to funding. I have *no* clue why that message is so difficult to get across. I *do* object to corporate products claiming to be community based. The sheer mass of "Swisscom" branding on the FreeNAC site makes it look like something other than a community project.
it would be no strings attached (bounty-like, resulting code solely licensed under GPL in freeradius, copyright retained by the author, ...).
"Bounty"? No thanks. If you want to pay for a feature, then standard business practice is to use a contract. I don't have much nice to say about bounties.
- Coordination with other related opensource project, especially TNC@FHH.
Which we've been doing for... years now. We've been very successful at it. Thanks for the offer of help, but we think we can manage. Maybe you're not clear on the positioning of FreeRADIUS versus FreeNAC. FreeRADIUS is almost a decade old. FreeNAC isn't. FreeRADIUS is used by most major ISP's. FreeNAC isn't. FreeRADIUS has an commanding market share in the LAN, WLAN, ISP, roaming, etc. authentication space. FreeNAC has minimal market share of the NAC market. FreeRADIUS has existing relationships with all major networking companies. FreeNAC doesn't. FreeRADIUS has a large active community with thousands of people on it's mailing list. FreeNAC doesn't. FreeRADIUS has a proven track record of being independent of any corporate agenda. FreeNAC doesn't. FreeRADIUS has an existing level of trust and acceptance in the community. FreeNAC doesn't. FreeRADIUS has existing relationships with *everyone* in the AAA space, and many people in the NAC space. FreeNAC doesn't. FreeRADIUS is writing industry standards in it's space. FreeNAC isn't. FreeRADIUS has done this *without* having "open source" and "enterprise" versions. FreeRADIUS has done this by first creating a community, and then a revenue stream. It sounds harsh when put that way. But the truth can be harsh. Remember, this isn't just a happy love festival of open source. There are multiple competing implementations of many open source solutions. Some succeed, some don't. On top of that, FreeRADIUS is winning in the AAA space against *Cisco* and *Microsoft*. FreeNAC just isn't on anyone's radar. So, good luck being successful. But don't expect us to be happy when your announcement makes it clear that you plan on building on our success, and treating FreeRADIUS as a subservient portion of FreeNAC. You wouldn't email Linus Torvalds and say that a FreeNAC product offering will become "THE open source choice for Operating Systems". But you said pretty much the same thing here. And then wondered why it wasn't greeted with loud exclaims of joy. I'm still boggling a little at that one.
A lot, I hope it'll start getting the two highly respectable but sometime emotive leaders on a more constructive mood (yes, I'll be flamed for that, I know, I know)
I have a habit of pointing out inconsistencies and flaws in peoples arguments. I have a habit of bringing up inconvenient facts that people don't want to talk about. This is construed as "negative" by many people.
PS : of course, I also have plans for total world domination - but I'll first start to become sean's boss. Then, I can move to mind-controlling hundreds of million of people.
FreeRADIUS is already the dominant player in it's space. It's *already* achieving world domination in the RADIUS space. FreeRADIUS already processes the logins of hundreds of millions of people. Your dreams are close to what we do daily. Alan DeKok.
Ok, we know and agree that freenac isn't in the same league as freeradius. The form of the announcement was a mistake we're now trying to correct. I'm really sorry it hurt you and would like you to formally accept my apologize for this bad communication. Would you agree to close that part of the discussion ? On 11/07/07, Alan DeKok <aland@deployingradius.com> wrote:
right. but I guess it should come after a 802.1x and a VPN client ... and those still don't exist
wpa_supplicant, xsupplicant, and SecureW2 are well-known GPL'd 802.1x clients. I've been in contact with those developers for years. There's already work on an open source 802.1x client with additional (i.e. NAC) features. Search the net.
sorry, this was a late email and I forgot important details like had in mind "with additionnal (NAC) features" and the "for windows" is implied by the vast majority of windows-based computers. so indeed, the most likely candidates are SecureW2 and open1x/opensea xsupplicant, but none of them are there yet. of course, a "a GPLed, ActiveX / Java / other browser-based endpoint posture assessment client, for use in fallback non-802.1x (walled-garden) mode." could also work after 802.1x
That's something already written by the TNC@FHH projects. Code is available here http://tnc.inform.fh-hannover.de/wiki/index.php/Download
I was in contact with them when they first wrote the code, quite a while ago.
Is there any plan to integrate that in the official release ?
Last I checked (quite a whole ago), the code wasn't GPL'd. It looks like it's changed since then. After a quick look, perhaps. The formatting should really follow the FreeRADIUS standard, it has C++ style comments, and some things likely need to be cleaned up. There's also the issue of which license libtnc falls under. On top of that, they haven't requested that it be added to FreeRADIUS.
so there's no plan, but a properly formatted, cleaned version would find its place ? (btw, libtnc is also GPL)
it would be no strings attached (bounty-like, resulting code solely licensed under GPL in freeradius, copyright retained by the author, ...).
"Bounty"? No thanks.
If you want to pay for a feature, then standard business practice is
to use a contract. I don't have much nice to say about bounties.
again, wrongly written sentence : bounty-like was to refer to the "no strings" that the result would end up as part of FreeRadius - nothing else. Of course, it would be made using a contract (and I also don't really like bounties, for the record). Would you be open to implement Microsoft's IF-TNCCS-SOH in that context ? dago
Hi,
of course, a "a GPLed, ActiveX / Java / other browser-based endpoint posture assessment client, for use in fallback non-802.1x (walled-garden) mode." could also work after 802.1x
It is actually quite important. If you are in a roaming scenario where your EAP session goes to your home ISP, it makes no sense to tie the posture information into the EAP session - it's the *access network* at the roaming place that needs to know how healthy your computer is. The home ISP at the other end of the world doesn't care that much. My general preference is that any NAC solution should keep *authentication* (EAP session) and *health assessments* in seperate channels. I'm happy that Cisco is following that line of thinking in their NAC solution, by offering a web-based or downloadable client *after* the EAP session if need be. It still *can* be tied into EAP, but it's optional. IMO, the way to go. Anyone implementing a NAC solution (i.e.: you) should keep this in mind, I'm glad you do. BTW, are you following the discussions in the IETF concerning NAC and friends (the "nea" - network endpoint assassment wg)? If this wg produces implementable results, your solution should be in line with it to ensure interoperability... It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-( Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
It is actually quite important. If you are in a roaming scenario where your EAP session goes to your home ISP, it makes no sense to tie the posture information into the EAP session - it's the *access network* at the roaming place that needs to know how healthy your computer is. The home ISP at the other end of the world doesn't care that much.
It cares a little. It may want to require certain software updates, too. But the local network cares more.
My general preference is that any NAC solution should keep *authentication* (EAP session) and *health assessments* in seperate channels.
That makes sense, but not everyone sees it that way, unfortunately.
BTW, are you following the discussions in the IETF concerning NAC and friends (the "nea" - network endpoint assassment wg)? If this wg produces implementable results, your solution should be in line with it to ensure interoperability...
I'm sure you've seen my messages on NEA... I have serious doubts about it. For a number of reasons.
It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-(
I understand it's useful to set requirements for network access. "You need a username, password, and a system that isn't susceptible to viruses". The pro-active scanning is nearly impossible to implement correctly. NEA largely seems like a group of people who want to standardize a pre-existing solution, and are surprised that there are people with different points of view. Alan DeKok.
Is it possible to have radius listen on multiple (but not all) ip's / interfaces on a server? Joe Vieira UNIX Systems Administrator Clark University - ITS 508.793.7287
Hello, I am curious about the methodology for using one authorization module for one type of service and another for a different type of service. basically we have wireless and VPN that is being authorized and authenticated through our radius box. i would like to be able to control authorization to each of those independently though different ldap attributes. I currently have it working with one ldap module, so both service are authorized thru the same attribute.... i am using freeradius 1.1.6 Any thoughts? Joe
Nevermind, i figured it out. Joe Vieira wrote:
Hello,
I am curious about the methodology for using one authorization module for one type of service and another for a different type of service. basically we have wireless and VPN that is being authorized and authenticated through our radius box. i would like to be able to control authorization to each of those independently though different ldap attributes. I currently have it working with one ldap module, so both service are authorized thru the same attribute....
i am using freeradius 1.1.6
Any thoughts?
Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 7/25/07, Joe Vieira <jvieira@clarku.edu> wrote:
Nevermind, i figured it out.
I have the same question. How did you figure it out? Joe Vieira wrote:
Hello,
I am curious about the methodology for using one authorization module for one type of service and another for a different type of service. basically we have wireless and VPN that is being authorized and authenticated through our radius box. i would like to be able to control authorization to each of those independently though different ldap attributes. I currently have it working with one ldap module, so both service are authorized thru the same attribute....
i am using freeradius 1.1.6
Any thoughts?
Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, 2007-07-11 at 08:33 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It is actually quite important. If you are in a roaming scenario where your EAP session goes to your home ISP, it makes no sense to tie the posture information into the EAP session - it's the *access network* at the roaming place that needs to know how healthy your computer is. The home ISP at the other end of the world doesn't care that much.
It cares a little. It may want to require certain software updates, too. But the local network cares more.
Interesting question (well - I think it's interesting) - would the local network trust the home network to tell it what the posture of the client is? Maybe by attribute on the Access-Accept? I think many roaming scenarios (e.g. eduroam federation) could probably get by usefully on that. Access-Accept Endpoint-Posture = "os:vendor=Microsoft" Endpoint-Posture = "os:product=Windows XP" Endpoint-Posture = "os:patchage=91230" Endpoint-Posture = "av:defage=31353" Endpoint-Posture = "av:vendor=Symantec" etc. Of course I could be talking rubbish ;o)
Hi,
I think many roaming scenarios (e.g. eduroam federation) could probably get by usefully on that.
Access-Accept Endpoint-Posture = "os:vendor=Microsoft" Endpoint-Posture = "os:product=Windows XP" Endpoint-Posture = "os:patchage=91230" Endpoint-Posture = "av:defage=31353" Endpoint-Posture = "av:vendor=Symantec"
painful. imagine keeping that file updated with what you think are the correct levels for revisions.... i see why Cisco quickly jumped off the software NAC bandwagon! ;-) no, what you need is a third-party program which is fed the Posture values by freeradius (think ntlm_auth or LDAP/SQL queries) and returns an OKAY, QUARANTINE or FAIL etc message which can then be acted upon. the 3rd party program would be a dedicated GPL open source tool community driven that is easily managed and gets the info about each AV vendor and patch level etc and can be further programmed to accept registry values and running software processes via same/additional client tools installed on the connecting machine (if such a tool is installed). OR it can be a proprietary software tool from a major vendor...that can accept the same queries and calls. your choice. the NAC part, though, would be 'trivial' as far as the RADIUS server is concerned. alan
On 11/07/07, Alan DeKok <aland@deployingradius.com> wrote:
It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-(
I understand it's useful to set requirements for network access. "You need a username, password, and a system that isn't susceptible to viruses". The pro-active scanning is nearly impossible to implement correctly. NEA largely seems like a group of people who want to standardize a pre-existing solution, and are surprised that there are people with different points of view.
Regarding some comments made earlier in NEA list, wouldn't an approach similar to microsoft ("statements of health" or SoH) would be a better solution ? In this case, the client would just send its status (SoH) and get an answer from the server (+ network access granted/isolated/denied). Granted, it is really a "microsoft-standard" (no implementation, but there are already backward compatibility requirements with previous version) - but the idea in general ? dago
Hi,
Regarding some comments made earlier in NEA list, wouldn't an approach similar to microsoft ("statements of health" or SoH) would be a better solution ?
In this case, the client would just send its status (SoH) and get an answer from the server (+ network access granted/isolated/denied).
Granted, it is really a "microsoft-standard" (no implementation, but there are already backward compatibility requirements with previous version) - but the idea in general ?
umm. Something like the following conversation on the wire? Net: How are you? comp: I'm fine, feeling good today. Net: Okay, welcome. The inherent problem is that a) the comps perception on whether it feels good or not doesn't necessarily match the requirements the network would like to enforce b) it's way too easy to just send "I'm fine". I'm sure you could quickly find a download of nifty little utility from gray-area website that simply always says that you're fine. The basic problem beneath this is that the network has to ask the *suspect himself* how it would judge itself. BTW, this is one of the MAJOR concerns I have with the NEA working group: the explicitly declared the integrity of the client-side piece of software "out of scope" for their working group. This is somewhat fatal, and undermines most of the efforts. At least, Cisco's solution delivers a piece of software from the server side, so that the network admin has control over the assessment software and can be reasonably sure it's trusted. Of course, that shifts the problems to the client (end user), who is supposed to trust that piece of software. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
BTW, this is one of the MAJOR concerns I have with the NEA working group: the explicitly declared the integrity of the client-side piece of software "out of scope" for their working group. This is somewhat fatal, and undermines most of the efforts.
At least, Cisco's solution delivers a piece of software from the server side, so that the network admin has control over the assessment software and can be reasonably sure it's trusted. Of course, that shifts the problems to the client (end user), who is supposed to trust that piece of software.
With the proliferation of virtual machine technologies and CPU support for such, I do not think it would be difficult for someone to spoof the software downloaded. The "Windows Genuine Advantage" client runs on WINE. The only way to ensure client-side trustedness is a TPM or similar, and that has a whole raft of other problems, both technical and political. I think it's pretty reasonable to say: """The working group declares the problem of any turing machine being able to simulate any other turing machine as out-of-scope.""" I haven't been following the NEA so their work might be rubbish, but the untrusted client-side nature of the software does not make it intrinsically worthless - the reason being that for someone to trick out the software, they have to EXPLICITLY install and configure some other software, which is a clear AUP violation and when detected (a system asserts it is patched gets hacked) can be dealt with at the appropriate level of severity with the organisations administrative (not technical) group.
Phil Mayers wrote:
I haven't been following the NEA so their work might be rubbish,
<cough> Absolutely NOT. *Never*. It will solve _all_ the problems of NAC.
but the untrusted client-side nature of the software does not make it intrinsically worthless - the reason being that for someone to trick out the software, they have to EXPLICITLY install and configure some other software, which is a clear AUP violation and when detected (a system asserts it is patched gets hacked) can be dealt with at the appropriate level of severity with the organisations administrative (not technical) group.
NAC is largely trying to solve a problem that is 3-4 steps away from the current administrator's work. 1) What's on my network -> many people don't know 2) What OS's are on my network 3) are they up to date 4) if so, virus, etc. matters rather a lot less. Alan DeKok.
I'm happy that Cisco is following that line of thinking in their NAC solution, by offering a web-based or downloadable client *after* the EAP session if
That has its own problems. If post-auth NAC is done with some kind of web download, you are then educating users to expect and trust code download via the browser - which is I think a very, very bad idea. It might work if there were a small number of implementations, signed and the certificates known and pre-trusted, but that's a monopoly and has the PKI tax. Then there are source availability and privacy issues. It also assumes that the endpoint will be *able* to execute the code (embedded platform, weird CPUs) and that the code will be able to asses the endpoint - a java (cr)applet that works on x86 linux might not work on PPC, ARM etc.
need be. It still *can* be tied into EAP, but it's optional. IMO, the way to
I think it's unlikely NAC and roaming will work at the same time, in the near future. As far as I can tell, the interest in NAC from customers is for compliance within the enterprise. One possible option I can think is the Cisco EAP-over-UDP solution - one could perform EAPOL back to your home institute to gain IP connectivity, then EAPoU to submit posture information to the *local* network - which then unblocks or restricts you at the IP level.
It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-(
"Presumed innocent" is a nice idea, but IMHO there are environments that simply doesn't work in. Financial institutes are one I can think of, and I could make convincing arguments based on my own experience that many academic networks (and CERTAINLY student residence networks) would benefit greatly from a default-deny. One thing that seldom gets talked about is the absence of TPM on many systems - making it reasonably trivial for 1st gen TNC-based clients to submit forged responses. This can only be handled at the administrative level e.g. formal disciplinary for any staff found running "TNCFaker" or whatever the random software that someone inevitably writes is called. It's a thorny problem no doubt. It'll be a few years before we start to see working, interoperable systems I think.
Hi,
One thing that seldom gets talked about is the absence of TPM on many systems - making it reasonably trivial for 1st gen TNC-based clients to submit forged responses. This can only be handled at the administrative level e.g. formal disciplinary for any staff found running "TNCFaker" or whatever the random software that someone inevitably writes is called.
It's a thorny problem no doubt. It'll be a few years before we start to see working, interoperable systems I think.
yep and you still get undone by those systems which dont run a standard OS and use the network.... squeezebox, PS3, xbox/xbox360, Wii/gamecube, slingbox, polycom videoconference, one thousand different printers and so on... alan
It's a thorny problem no doubt. It'll be a few years before we start to see working, interoperable systems I think.
yep and you still get undone by those systems which dont run a standard OS and use the network.... squeezebox, PS3, xbox/xbox360, Wii/gamecube, slingbox, polycom videoconference, one thousand different printers and so on...
Interestingly I played with an Axis video encoder box (little embedded linux system) recently, and it has an 802.1x client on board - so the trickle is starting.
It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-(
"Presumed innocent" is a nice idea, but IMHO there are environments that simply doesn't work in. Financial institutes are one I can think of, and I could make convincing arguments based on my own experience that many academic networks (and CERTAINLY student residence networks) would benefit greatly from a default-deny.
Right, but machines on a residential network are generally going to be personal machines, I for one would protest greatly if I was forced to install an AV solution just to use the network in my halls of residence. It's fine dictating what is installed on University owned machines, but users personal equipment is their *own*, and they should be able to manage it how they see fit. If you feel like experimenting a little, you can always stick a snort probe at a key point in your infrastructure. Then make decisions as to whether the user should be segregated from the main network, based on the information gathered about what their machine is actually doing. Also means theres no extra burden on the users... and anything that makes the users life simper , generally means less hastle for the people supporting that user .
Hi,
Right, but machines on a residential network are generally going to be personal machines, I for one would protest greatly if I was forced to install an AV solution just to use the network in my halls of residence.
our terms and conditions state that an AV solution must be installed on such systems. the users are free to choose their own one if they want to, or they can freely install a fully managed McAfee AV with the anti-spyware module for free as part of the service. we dont want to be a breeding ground for external attacks, we try to protect our students from losing all their coursework due to an MSN installed trojan or virus and we want to instill them with a bit of knowledge of protecting their computers. whilst they're here, their systems are a little more 'looked after' from the net. when those machines go home for holidays etc they will be largely wide open to attack....we didnt like the huge surge of bad traffic after the holiday season when their systems came back with more diseases than i would have if I went down to the Congo with not a single jab and a penchant for swimming in the local rivers. we've looked at various NAC systems over the past few years and although its very desirable for systems to 'pass a test' before they are allowed on the main network (imagine you start on a side road...you havent got AV..install AV..get onto main road..you are not patched...patch system...get onto motorway) none of the current solutions were desirable for various niggling issues - and for simpler reasons such cross-platform support, dealing with dumb systems etc. alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Right, but machines on a residential network are generally going to be personal machines, I for one would protest greatly if I was forced to install an AV solution just to use the network in my halls of residence.
our terms and conditions state that an AV solution must be installed on such systems. the users are free to choose their own one if they want to, or they can freely install a fully managed McAfee AV with the anti-spyware module for free as part of the service. Same, though we offer F-Secure. we dont want to be a breeding ground for external attacks, we try to protect our students from losing all their coursework due to an MSN installed trojan or virus and we want to instill them with a bit of knowledge of protecting their computers. whilst they're here, their systems are a little more 'looked after' from the net. when those machines go home for holidays etc they will be largely wide open to attack.... Same, though computers are counted as students own responsibility. To combat infections spreading from computer to computer, we assign everyone on resnet/roaming an ip with a cidr subnet mask of 24. Though I think this is pretty standard practise on most residential networks these days. we didnt like the huge surge of bad traffic after the holiday season when their systems came back with more diseases than i would have if I went down to the Congo with not a single jab and a penchant for swimming in the local rivers.
Or urinating in the local rivers ... Nasty little fishys
we've looked at various NAC systems over the past few years and although its very desirable for systems to 'pass a test' before they are allowed on the main network (imagine you start on a side road...you havent got AV..install AV..get onto main road..you are not patched...patch system...get onto motorway) none of the current solutions were desirable for various niggling issues - and for simpler reasons such cross-platform support, dealing with dumb systems etc.
Yes, Macs *nixes, *nuxs... etc Impossible to support them all ... you could just require that all windows boxes have AV, as they're the ones most at risk. Or just ban all windows pcs by default, due to inherent insecurities in the operating system :)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, 2007-07-12 at 12:46 +0100, Arran Cudbard-Bell wrote:
It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-(
"Presumed innocent" is a nice idea, but IMHO there are environments that simply doesn't work in. Financial institutes are one I can think of, and I could make convincing arguments based on my own experience that many academic networks (and CERTAINLY student residence networks) would benefit greatly from a default-deny.
Right, but machines on a residential network are generally going to be personal machines, I for one would protest greatly if I was forced to
You could protest all you wanted; *if* we had implemented that policy then it would have been signed off by the student union, senior tutors and college IT security advisory group, and it would have been in the wording on the bit of paper you sign when you join the university. We've done this with lots of other policies (e.g. 5Gb/24 hours bandwidth limit - exceed it once and you're off for 48 hours, 2nd time and it's 2 weeks and 3 times, you're off for the rest of the academic year) and it works fine.
install an AV solution just to use the network in my halls of residence. It's fine dictating what is installed on University owned machines, but users personal equipment is their *own*, and they should be able to manage it how they see fit.
I have no intention of forcing people to install software to get onto the network. But when they get kicked off into a BANNED vrf, after the first offense we require that they prove their machine is clean before they get back on. At the moment, that means they physically carry it to the helpdesk. Were the option available, running some kind of software agent that we supply seems like a clear win. People focus rather too much on the "initial access" bit of NAC, and seem to ignore the remediation benefits.
If you feel like experimenting a little, you can always stick a snort probe at a key point in your infrastructure.
We have extensive IDS and IPS systems setting between our residence network.
Then make decisions as to whether the user should be segregated from the main network, based on the information gathered about what their
The residences systems ARE segregated from the main network, always and forever - they live in a VRF and hit a firewall before coming into the main production zone.
Phil Mayers wrote:
On Thu, 2007-07-12 at 12:46 +0100, Arran Cudbard-Bell wrote:
It's another topic that I'm overall sceptical of NAC, IMO a network should only reactively shut a client down *after* it did something wrong, not proactively sniff around the local environment and lock it away at once. But NAC is here to stay I guess. :-(
"Presumed innocent" is a nice idea, but IMHO there are environments that simply doesn't work in. Financial institutes are one I can think of, and I could make convincing arguments based on my own experience that many academic networks (and CERTAINLY student residence networks) would benefit greatly from a default-deny.
Right, but machines on a residential network are generally going to be personal machines, I for one would protest greatly if I was forced to
You could protest all you wanted; *if* we had implemented that policy then it would have been signed off by the student union, senior tutors and college IT security advisory group, and it would have been in the wording on the bit of paper you sign when you join the university.
Oh you have one of those political infrastructure things .. We have an AUP policy which students have to accept before we allow their machines onto the network, and it does stipulate that users should have an up to date antivirus solution, but we don't explicitly enforce it.
We've done this with lots of other policies (e.g. 5Gb/24 hours bandwidth limit - exceed it once and you're off for 48 hours, 2nd time and it's 2 weeks and 3 times, you're off for the rest of the academic year) and it works fine.
Thats a pretty harsh policy, considering the residential network here uses at least 40mbit/s downstream b/w at any given time throughout the day, i'd say most of our students would use up their 5gb quota pretty fast. We use rate limiting here instead, based on the number of connections over a given period of time. This only targets really targets p2p traffic, and leaves everyone else undisturbed. We inform the students that they have been rate limited, and that they may be experiencing a slow connection, but there are no permenant blocks or bans in place, so after a period of time they automatically get the rate limiting removed. Eventually they learn ...
install an AV solution just to use the network in my halls of residence. It's fine dictating what is installed on University owned machines, but users personal equipment is their *own*, and they should be able to manage it how they see fit.
I have no intention of forcing people to install software to get onto the network.
But when they get kicked off into a BANNED vrf, after the first offense we require that they prove their machine is clean before they get back on. At the moment, that means they physically carry it to the helpdesk.
Our helpdesk staff would absolutely hate us if we tried that here !
Were the option available, running some kind of software agent that we supply seems like a clear win.
So say I'm doing something perfectly legitimate with my embedded *nux box, and your IDP system bans me for some reason ... do your helpdesk staff have the technical knowlege to check that my *nux box is safe and secure ? Or do they feed me some line about having to install a supported operating system, and an AV client from a recognised commerical vendor ?
People focus rather too much on the "initial access" bit of NAC, and seem to ignore the remediation benefits.
If you feel like experimenting a little, you can always stick a snort probe at a key point in your infrastructure.
We have extensive IDS and IPS systems setting between our residence network.
Do you get many false positives ?
Then make decisions as to whether the user should be segregated from the main network, based on the information gathered about what their
The residences systems ARE segregated from the main network, always and forever - they live in a VRF and hit a firewall before coming into the main production zone.
Yes ours sit behind a cluster of routing firewalls. What I meant by main network was a network other than a "quarantine" network.
On 12/07/07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On Wed, 2007-07-11 at 08:33 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It is actually quite important. If you are in a roaming scenario where your EAP session goes to your home ISP, it makes no sense to tie the posture information into the EAP session - it's the *access network* at the roaming place that needs to know how healthy your computer is. The home ISP at the other end of the world doesn't care that much.
It cares a little. It may want to require certain software updates, too. But the local network cares more.
I still can't imagine those use cases (they probably exist, but I just don't see them) The home network can always check the security when entering the home network via VPN (for example). As for local access, it can't relied upon to guarantee that the endpoint will always be secure when connecting to any other local network - NAC won't be everywhere. On 12/07/07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
need be. It still *can* be tied into EAP, but it's optional. IMO, the way to
I think it's unlikely NAC and roaming will work at the same time, in the near future. As far as I can tell, the interest in NAC from customers is for compliance within the enterprise.
One possible option I can think is the Cisco EAP-over-UDP solution - one could perform EAPOL back to your home institute to gain IP connectivity, then EAPoU to submit posture information to the *local* network - which then unblocks or restricts you at the IP level.
yes, it was the example of "separated channels" I can think of, but as any similar solution based on layer 3, it won't solve all problems, and in particular, can't isolate on a particular network without making some VLAN reconfiguration or chokepoint. for this, there's very few room because the VLAN would be given after the 802.1x authentification. On 12/07/07, A.L.M.Buxey@lboro.ac.uk <A.L.M.Buxey@lboro.ac.uk> wrote:
no, what you need is a third-party program which is fed the Posture values by freeradius (think ntlm_auth or LDAP/SQL queries) and returns an OKAY, QUARANTINE or FAIL etc message which can then be acted upon. the 3rd party program would be a dedicated GPL open source tool community driven that is easily managed and gets the info about each AV vendor and patch level etc and can be further programmed to accept registry values and running software processes via same/additional client tools installed on the connecting machine (if such a tool is installed).
well, that's the idea behing TNC (or at least that's what they described in the architecture document as an example). - Network Access Authority [freeradius, for example] first authentify the user - then pass the TNC messages to the server (back & forth) - TNC server make sure everything's ok - then given recommandation to NAA - Which sends the answer. as for implementation, that's what is done by FHH (see dataflows on page 28 of http://tnc.inform.fh-hannover.de/wiki/media/7/76/Overview_of_AR_and_PDP_in_T... ). In fact, it's not fed really the posture values by freeradius, but the TNC messages. It also cannot be multiplexed by default. I don't know that much about EAP roaming (not edu), so I can't say it may solve roaming issues, but that's doesn't seem undoable dago
Thomas Dagonnier wrote:
The home network can always check the security when entering the home network via VPN (for example).
And when the machine is roaming? The two sites may have a trust relationship. In that case, the local site may ask the remote site if the machine is OK. Why would I let your machine on my network if your administrator says it has viruses? Alan DeKok.
Thomas Dagonnier wrote:
Would you agree to close that part of the discussion ?
Fine.
sorry, this was a late email and I forgot important details like had in mind "with additionnal (NAC) features" and the "for windows" is implied by the vast majority of windows-based computers.
wpa_supplicant works on Windows. It's already been accepted into nearly all Linux & BSD distributions, too.
so indeed, the most likely candidates are SecureW2 and open1x/opensea xsupplicant, but none of them are there yet.
Notice how the OpenSEA announcement included a quote from me, and mentioning FreeRADIUS?
so there's no plan, but a properly formatted, cleaned version would find its place ?
As always, patches are welcome.
Would you be open to implement Microsoft's IF-TNCCS-SOH in that context ?
If someone sends a patch, yes. I'm too busy to do the work myself. Alan DeKok.
On 11/07/07, Alan DeKok <aland@deployingradius.com> wrote:
Thomas Dagonnier wrote:
Would you agree to close that part of the discussion ?
Fine.
sorry, this was a late email and I forgot important details like had in mind "with additionnal (NAC) features" and the "for windows" is implied by the vast majority of windows-based computers.
wpa_supplicant works on Windows. It's already been accepted into nearly all Linux & BSD distributions, too.
and it implemented TNC end of last month (oops, that was already 2 months ago). and I guess opensea will come in 1 month (according to their timeframe). I was just saying that 802.1x TNC (or NAC) capable supplicant were more important than applets - IMHO
Notice how the OpenSEA announcement included a quote from me, and mentioning FreeRADIUS?
yes, I noticed - but are you taking an active role there or just supporting by helping with freeradius (as a reference, std-based radius server) ?
so there's no plan, but a properly formatted, cleaned version would find its place ?
As always, patches are welcome.
Would you be open to implement Microsoft's IF-TNCCS-SOH in that context ?
If someone sends a patch, yes. I'm too busy to do the work myself.
Ok. I guess it may have something to do with that 2.0 thing (not web 2.0 - hopefully). thanks for answering, thomas
Thomas Dagonnier wrote:
yes, I noticed - but are you taking an active role there or just supporting by helping with freeradius (as a reference, std-based radius server) ?
I'm watching it. There's only so much time in a day. Alan DeKok.
Sean.Boran@swisscom.com wrote:
My focus was to offer "LAN Access Control", what many people call "NAC".
Switches already do 802.1x for LAN access control. They use RADIUS.
To me there was no solution for that, from systems management point of view.
Packet Fence is widely known and widely used. Netreg is older, but perhaps not as actively developed. There were existing solutions in this space before FreeNAC was started.
It wasn't a provocation, really. I did not think FreeRadius sees itself as a NAC server.
Again, you are not understanding. The announcement didn't say "the NAC solution". It said "the WLAN authentication" solution. The reality is that FreeRADIUS is already the WLAN authentication solution. And, of course, when I point that out, you try to pretend my attitude is because your project is doing NAC.
The idea of the consulting is to try and get some funding to ensure the long term survival. I did not think of GPL and funding as mutually exclusive, but you do?
I said "FreeNAC, like some other projects, appears largely to be a way to generate consulting revenue. That isn't a bad thing, as people have to make money." If you have to ask whether or not I think GPL & funding is mutually exclusive: a) you didn't read my post b) you read it, but you didn't understand it c) you're being a jackass
You can have SVN access if you want.
Great! Do I get part of the funding from selling the enterprise version? Do I have to participate in supporting the enterprise version? Do I even *know* who's buying the enterprise version? Given corporate agendas, the reality is that there will be two core teams. One composed of Swisscom people who deal with the enterprise customers, and another, which includes the "community". This is not anything nefarious on the part of Swisscom, but it's the only way to make these kinds of dual corporate/community projects work. The only way to have *one* core team is to set up a legal "FreeNAC" entity separate from Swisscom, and have membership determined by FreeNAC, not by Swisscom. i.e. That's how everyone else on the planet runs these kinds of projects. Your disclaimer that it's a "community" effort is a little disingenuous.
Is the ISC GPL?
Does Google have a search engine?
Good. Perhaps you could explain your CVS commit policy, or what we should do differently?
That was the CVS commit policy.
My intention *is* to create a community with a consulting spinoff, not the other way around.
That's not the way the project is structured right now. Look at Packet Fence for a NAC solution that's widely deployed, and which makes a clear distinction between the community and corporate areas.
As regards WLAN, I only mentioned that as an aim, because its turns out that if you doing LAN access control on wired LAN, its useful if it can do wireless too.
Yes. So it makes sense for you to claim that by integrating FreeRADIUS, you would become the leader in WLAN authentication. It's like me saying I'm the King of Linux because I burned a CD the other day with Linux on it.
Well it's a pity I didn't know that, that really was not the aim, but I guess the damage is done now.
If your aim was collaboration, it would be clear in everything you say and do that your aim was collaboration. Instead, the words you use are synonyms for "subsume" and "take over".
VMPS is only one part of the problem. Do you want to add a Database, Client Security tools/interfaces, policy engine, interfaces to AntiVirus servers, scanners, Patch servers, and so to FreeRadius? I thought Freeradius concentrates on the authentication protocols, not the network integration aspects?
I see. Apache is an implementation of the HTTP protocol, and doesn't include any kind of integration with databases, policies, client tools, management interfaces, policy engines, etc. Right? Isn't that how protocol implementations are done? Your view of FreeRADIUS as a simple implementation of the RADIUS protocol is either ridiculously naive, or very self-serving. If you had cared to look (and it's obvious that you haven't looked, or that you're pretending you haven't looked), FreeRADIUS has had database integration since the start, almost a decade ago. It has had client tools, and a management interface (dialup-admin) for almost a decade. It has had a policy engine for almost a decade. So far as network integration, FreeRADIUS is whatever the community needs it to be. If you read the web site, you'll see that it's grown to include a BSD licensed client implementation. It's grown to include VMPS. This allows it to do cross-protocol integration of information, and use it's "policy engine" to store that information in a "database", and to display it in the "administration interface" that comes with the server. If the core value of FreeNAC is (s you said) at the "policy level", then the release of a VMPS server with a powerful policy language and database integration should have been a tremendous boon for FreeNAC. Especially since FreeRADIUS supports VMPS policies in LDAP, Perl, or Python, Oracle, Postgresql, etc. which OpenVMPS (and FreeNAC) do not currently support. Was VMPS support in FreeRADIUS a pleasant surprise? Or do you view it as being negative for FreeNAC? Please explain. Alan DeKok.
participants (9)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Clark J. Wang -
Joe Vieira -
Phil Mayers -
Sean.Boran＠swisscom.com -
Stefan Winter -
Thomas Dagonnier