RE: new to VPN

[Stephen Kent <kent@bbn.com>]

At 10:35 AM -0800 2/3/03, John Lindal wrote:
>  > There's a very large difference between a general purpose OS like
>>  Windows or Unix, and an embedded system OS.  Large, as in several
>>  orders of magnitude.
>
>Unless I'm missing something fundamental, comparing the raw sizes of
>various operating systems is misleading.  Assuming that the VPN software is
>installed at the bottom of the network stack, just above the NIC driver,
>then it doesn't matter how big the rest of the OS is.  The only thing that
>matters is the tiny little bit of the OS that takes the packet off the NIC
>and hands it to the VPN driver.
>
>Of course, this small part of the OS must not have any holes, the VPN
>software must not have any holes, and the security policies must be set
>correctly to weed out malicious or unwanted packets!

I'm afraid you are missing something. Irrespectivbe of where the VPN 
software is installed in a general purpose platform/OS environment, 
that software can be subverted by a successful attack against any 
part of the rest of the OS. Your comment suggests that if the VPN 
access controls are working, then no evil packets can evade detection 
and thus be used to attack the higher layer software. We have lots of 
experience that indiactes otherwise.


>-----
>
>Somebody also brought up the issue of key security in hardware vs software
>implementations.  Given the above scenario of a correctly implemented VPN
>driver as close to the NIC as possible, one can only steal keys if one has
>physical access to the device.  When this happens, it seems to me that
>neither hardware not software will deter a determined attacker, though it
>is harder to break into a device that doesn't have a keyboard :)

One can steal keys that are protected by software if an attacker 
gains control of the device via any means, period. This includes any 
form of remote attack, not just local, physical attacks. In contrast, 
a FIPS level 3/4 device is tested to be immune to extraction of 
plaintext keys, even in the face of most physical attacks.

>Of course, if one uses certificates and a centralized management system,
>then it is trivial to revoke a certificate if a computer is stolen or
>otherwise compromised.  Just don't try this trick with pre-shared text keys :)

If one knows the keys have been compromised revocation is a solution. 
For pre-shared keys, in a client-sever context (which seems to be the 
primary context you and your colleague are addressing), revocation is 
also easy re a client compromise, since only the enterprise (server) 
needs to know of the revocation.  Again, a level 3 device provides 
evidence of tampering to extract keys (level 4 should prevent such 
extraction) which then provides a trigger to revoke certs.

>Add in user level authentication for road warriors, and it becomes highly
>unlikely that anybody will be able to break into the rest of the network
>before the certificate is revoked (assuming that employees conscientiously
>report stolen laptops, of course!).

This last comment is based on the assumption that only a detected, 
physical attack could extract keys. This is not true in general, and 
in the case of a laptop, copying of the contents of the (presumably 
encrypted) keys from the hard drive could be effected without theft 
of the laptop, and without leaving evidence of the extraction. Then 
one can proceed to offline recovery of the keys, which have probably 
been encrypted via a password. I agree that this specific scenario is 
not the most common one to worry about, unless road warriors are 
working in contexts where this sort of black bag job is a concern. 
Nonetheless, I think the example illustrates why reliance on 
revocation is less attractive than reliance on hardware to protect 
keys in the first place.

Steve