> -----Original Message-----
> From: Bennett Todd [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 17, 2000 10:57 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Reasonable disclosure
>
>
> 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.
"Excepting that one issue" is what got me started with questions in
the first place. Distrusting security through obscurity, I assumed that, if
CheckPoint's solution does have that 'one issue', they would acknowledge the
fact, and explain why it doesn't matter.
>
> > (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.
Theoretically, a man-in-the-middle could send the server a bogus
public key, claiming to be from my SR client and causing the server to
distrust the client. Are real world solutions not expected to toe the line
so precisely in terms of implementing a conceptual scheme? (I don't think
it's a big deal, I'm just kind of new at all this. I don't know what
standards of implementation are considered acceptable.)
> > 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.
DH allows, through the exchange of _public_ keys, the calculation of
a shared secret. But that shared secret never gets sent down the wire. So
it seems like a serious breach of protocol if CheckPoint's solution
literally 'exchanges a session key'. Unlike the above point, this would
seem like a big deal to me.
> > 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.
>
Good point. Thanks.
Steve
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
