Re: NAC

2007-07-13 Thread Thomas Dagonnier
On 11/07/07, Alan DeKok <[EMAIL PROTECTED]> 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
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: NAC

2007-07-13 Thread Thomas Dagonnier
On 12/07/07, Phil Mayers <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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_TNC%40FHH_by_Martin_Schmiedel_%28english%29.pdf
). 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
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Freeradius 2.0 - vmps feature, accuracies on FreeNAC

2007-07-12 Thread Thomas Dagonnier
On 11/07/07, Alan DeKok <[EMAIL PROTECTED]> 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
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Freeradius 2.0 - vmps feature, inaccuracies on FreeNAC

2007-07-10 Thread Thomas Dagonnier

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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius 2.0 - vmps feature, inaccuracies on FreeNAC

2007-07-10 Thread Thomas Dagonnier

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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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


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 [EMAIL 
PROTECTED]



* 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, OTO