2000-03-17-10:04:10 [EMAIL PROTECTED]:
> In particular, I want to understand _conceptually_ how the FW1
> server and SR client agree on a shared session key. CheckPoint's
> documentation claims that the server and client use the
> Diffie-Hellman scheme, but I don't see how that can be. There is
> no Certificate Authority to validate to the FW1 server that the DH
> public key from my SR client is authentic. So I don't see how the
> server can generate a session key.
I think you're conflating encryption with authentication. Encryption
requires somehow generating a shared secret, to be used as the key
for the encryption algorithm. Diffie-Hellman is great for that. It
requires no preexisting secret, and at the conclusion of the
algorithm the two participants share a common secret which an
external observer can't have deduced. Since it does not in and of
itself include an authentication protocol (which, by definition,
must use some pre-shared secret or certificate authority system)
Diffie-Hellman offers no protection against a man-in-the-middle
attack. Fortunately, they still aren't all that easy to mount in
practice. But excepting that one issue, once you have a suitable
session key established, the client can authenticate to the server
using a simple password.
> (There _is_ a CA for the server's DH key, and I understand how my
> client uses the CA to get the server's DH public key).
Well, if the client can authenticate the server, then I believe that
rules out the man-in-the-middle attack, so it sounds like they have
things covered.
> CheckPoint's documentation also says that the SR client 'exchanges
> a session key with the SecuRemote server and loads it into the
> SecuRemote server" (VPN-1 manual, p. 104). Perhaps I have
> misunderstood something, but isn't it the point of the whole DH
> scheme to avoid exchanging keys?
I think the whole point of DH is to allow, through the DH exchange,
the distributed negotiation of a shared secret session key.
> Well, CheckPoint won't tell me, claiming proprietary this and that.
Given what you've said of their claims, I don't seen a clear and
obvious hole from a crypto theory point of view.
But if you're using something like CheckPoint, you really need
to relax your standards of "disclosure"; using a closed-source
proprietary firewall is saying that you completely trust the vendor
to keep you secure, and are willing to relinquish responsibility for
things like reviewing the design and implementation of their product
to them.
This is the main reason that some of us do not specify proprietary
code for critical security barriers.
-Bennett
PGP signature
