NAC

[Phil Mayers]

> 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.