2000-03-17-11:41:46 [EMAIL PROTECTED]:
> > But excepting that one issue [man in the middle --- MITM], 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.
Well, DH alone doesn't address MITM, but it's a building block, and
with suitably chosen other components in the whole algorithm perhaps
it is addressed.
> 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.
I don't _think_ the commercial firewall vendors are focused on the
market that hotly objects to security through obscurity. There used
to be one exception, Trusted Information Systems, who shipped source
with their Gauntlet product, which ran on a well-supported Unix
platform. Sadly, they were bought out by NAI, have made source much
much harder to get at, have dropped support for BSDI in favour of
NT, and generally cast their vote with the rest of the firewall
industry. Happily, this loss just about coincided with the
availability of such nice open source building blocks that you can
build a better firewall from scratch easier than you could configure
a Gauntlet.
> > > (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.
As I understand it, DH is being used to allow the client and the
server to securely negotiate a shared secret; the client has the
benefit of a CA allowing them to authenticate the server; and the
server looks for a password or some other such thing from the
client, coming over the encrypted channel after the key exchange
completes, for the client to authenticate. If these assumptions are
all correct, then all a MITM could do is prevent the connection from
setting up --- if the MITM tried to intrude, the client wouldn't
handshake with it unless it used the server's real public key (due
to the CA), and if it used the servers real public key and the
client's real public key, it wouldn't be able to glean the shared
secret that's being computed in the DH exchange. So the only thing
it could fake out would be the client side of the exchange. The
client would never handshake with a MITM who couldn't produce
suitably signed creds. So with one side of the original DH
authenticated, the MITM is locked out of the crypto tunnel. All they
can do at that point is just try to pretend to be a client, cold;
that would work right up until the point where the client had to
present a valid password through the crypto tunnel, then the
breakin would stop.
Sure, an MITM can DoS a connection. That's the nature of being in
the middle, you can break connectivity. But I don't see how they can
compromise either end of the connection, given what you've said
about the protocol.
> > > 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.
I think there's a misunderstanding here. The way I read the original
quote --- "exchanges a session key" --- that's just what the DH is
doing. DH is used to securely negotiate ("exchange") a session key,
which gets used by ("loaded into") the server. Perhaps the wording
is a little sloppy, but it's not obvious to me that it says that
they first use a secure key-exchange protocol, then take the
resulting shared secret and reveal it to the world by passing it
from one end to another that already has:-).
-Bennett
PGP signature
