RE: [Nea] RE: Detecting Compromised Endpoints
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Nea] RE: Detecting Compromised Endpoints
Marcus,
The problem is that all devices out there that run software are targets
to malware. This includes VPN Gateways, routers, firewalls, etc. etc.
Just because we have not seen malware attacking these devices, it does
not mean it will not happen. Perhaps its just a matter of time.
Anyways, we should focus on NEA (which should be focusing on *protocols*
for interoperability :)
Cheers,
/thomas/
-----Original Message-----
From: Marcus Leech [mailto:mleech at nortel.com]
Sent: Friday, May 26, 2006 4:52 AM
To: Thomas Hardjono
Cc: nea at ietf.org; Frank Yeh Jr
Subject: Re: [Nea] RE: Detecting Compromised Endpoints
Thomas Hardjono wrote:
> Thanks Frank - yes, you are spot on.
>
> My understanding as to how the discussion drifted to trusted hardware
> arose from some questions in the IETF.
>
> Basically, some folks at the IETF were suggesting that we don't bother
> with NEA because (a) any posture agent on the client can be modified
> by malware (to then forge posture reports); and (b) They don't believe
> in trusted hardware or even the possibility of secure systems.
>
> The funny thing is that virtually all protocols invented in the IETF
> is subject to changes by malware in (a). This includes IPsec VPN
> clients, routing code, NAT boxes, and even the entire IP stack.
>
I was going to simply let my contributions to this thread die, having
said what I wanted to say.
But this just has to be answered. There's a fundamental difference
between compromise of something like an IPSEC
client, and compromise of an agent. If I compromise an IPSec client
in some way, it doesn't affect the security
state of the VPN gateway, only that of the client.
In the TCG scenario, security decisions made by the network as a whole
rely entirely on the agent behaving
correctly, including not having been compromised. You're making
security decisions based on information
that can't be independently verified. When I assert that I'm
mleech at nortel.com to some gateway or NAS
or whatever, my credentials (password, certificates, etc) act as a
method of "indepenent verification" of my
mleech at nortel.com assertion. Just because a remote,
turing-complete, machine *asserts* that it is sane, and
has notarization to "prove" it, doesn't necessarily make it so, and
there's no way for the network infrastructure
to verify those assertions with the same kind of solidity as verifying
my mleech at nortel.com assertion by way
of credentials. No amount of cryptographic mumbo-jumbo can get around
that very fundamental problem,
IMHO.
Anyway, I'm done. Everyone knows what my opinion is on the fundamentals
here, but to the extent that we
all have drunk the kool-aid at some level, there needs to be protocol
standards, and *that's* what NEA
is all about.
> Perhaps we should just give-up on the Internet :)
Well, that's a whole other topic :-)
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.