Re: IPsec and firewalls

[Adam Shostack <adam () homeport org>]

        I'm going to pick crypto and crypto political nits here.

        First, the phrase trusted third party has been transformed to
mean the National Security Estamblishments of Major Governments, ie,
beyond the NSA and their foriegn subsidiaries, it also includes
national and local law enforcement in a variety of places.

        What we want, I think, is not a trusted third party, but an
authorized man-in-the-middle.  Its not a third party in the sense of
being an external organization in which your trust is placed by the
vendor or the law.  Its an internal, controlled extension of trust to
a machine which implements your security policy, or a subset of it.

        I agree with Aleph that theres a market for this, but don't
know if this was considered as a design criteria in OAKLEY/ISAKMP; the
ability to safely send a key to a third party.  I suspect not; the
issues are complex enough that it will need to be considered
seperately.  Those issues include when to send the keys (hopefully at
the end of the negotiation, after the randomness has been well
hidden), who send the keys (probably the client if, eg, you're sshing
out, but if I connect to a web server via SSL, going through a
firewall locally, and a firewall at the remote end, which do I send
keys to?), and how to represet all of this usefully to the user.

        Regarding Carson's points about making your firewall a CA, I
think that for any company which has more than a few servers
internally, making the FW a Certification Authority is a mistake.  A
CA *certifies* keys.  In the X509 model, it ties a name to a key.  In
the SPKI model, it certifies that an authorization is enabled for a
key.  In the PGP model, it certifies that something has been
certified-the implication is usually that a name is tied to a key.  CA
machines, irrelevant of their use of hardware key storage, should be
air gapped.  They do not need to be online, they are a high value
target, and they need all the security they can get.  I say irrelevant
of hardware because unless they are running a B1 or better OS, I have
zero confidence that the hardware is not being fed bogus requests by
an untrustworthy program.

        In the model proposed by many, your keys are your identity.
Read the Utah Digital Signature act.  There is a requirement that the
user of a key excerise due dilligence.  Your key is authorized to do
many things for you.  Failure to properly revoke by a CA (I'll rant on
that another day) does not protect you.  There is no consumer
protection.  What this means is, if I steal your certified CA private
key, and sign a key that declares me able to sign checks for your
company, I can.  There may be theft and fraud from the point of view
of stealing the CA key, but its roughly equivallent to forging the
CEOs signature and company seals on a letter making me CFO.

        So, I advise for air gaps for your CA, or at the very least,
burying it deep in your organization.  Don't put it on your firewall.

        I suspect that Carson knew this, and misspoke, hitting one of
my pet peeves. :) 

Adam


carson () tla org wrote:
| >>>>> "Aleph" == Aleph One <aleph1 () dfw dfw net> writes:

| Aleph> and RCS1826). I was just talking to someone about this at USENIX. I see a
| Aleph> market for someone that implements and ISAKMP daemon that supports
| Aleph> transfering keys to a trusted third party. Of curse this brings you all
| Aleph> the same headackes that Kerberos does having to maintain a secured machine
| Aleph> with possible all session keys but hopefully your firewall maintains that
| Aleph> level of security so it should not add many more risks. Probably any such
| Aleph> protocols between the ISAKMP server and the firewall should be standarized
| Aleph> by a RFC. Anyone have any comments?
| 
| _Every_ authentication scheme relies on a trusted 3rd party of some
| sort. The only question is who is trusted, and when that trust must be
| validated. If you make your proxy/firewall/nat/whatever a trusted CA, you
| can proxy just about anything, including stripping ActiveX from HTTP over
| SSL sessions. I agree that it would be nice for this "trusted spoofing" or
| "friendly man in the middle" approach to be designed in rather than
| reverse-engineered.

-- 
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume