[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: notes from developer's portion of IETF meeting

-----BEGIN PGP SIGNED MESSAGE-----


In message <199704240712.JAA03901@wave.fwl.dfn.de>, Uwe Ellermann writes:
>
>Considering a VPN scenario using tunnel-mode ESP, mandatory
>integrity for ESP wouldn't gain much more security, iff all
>tunneled IP packets are already required to use AH by the 
>site's policy. It should be possible to save the additional 
>overhead of applying integrity mechanisms twice (ie. AH and ESP) 
>on the same data.

So your end host is creating packets with an AH header. Who can verify
this AH header ?
- - Your local firewall: Not useful in the general case. All it does it
  further assure the firewall that you're who you claim you are. But
  since the packets appear on the trusted network, this is already
  implied. In this case, the local firewall would strip that header,
  add an ESP(*) header to the remote firewall and send the packet out.

- - The remote end host: How would the remote firewall know when to let
  packets in ? Remember, it can't verify them. In this case, your
  local firewall would add the ESP header to prove to the other
  firewall that the packet came from a trusted network (VPN and all 
  that). Usually, this AH SPI would be established after the firewalls
  themselves have established an ESP SPI.

- - The remote firewall: In that case, you don't really need the local
firewall to do anything; you should use ESP to the remote firewall,
and the local firewall should do nothing. This would imply that your
administrator trusts you not to violate the VPN. If he doesn't, then
you shouldn't be able to establish an SPI with the remote
firewall/host in the first place (wouldn't allow the KMP to run in
proxy mode, or whatever it's called today).

- - A (sub)set of the above: we don't have group shared keys (yet ?).

(*) ESP with authentication

So i think the scenario you presented is unrealistic.
- -Angelos


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM1/La70pBjh2h1kFAQFw8QP/aUZQ+RPttO4kr6K1W44NBaVV86tPpBNU
zVl7VVF3bYILoqmLvFuYeehAr5b5WWJL51wlYU8lH6tpCXMAZAxWzFmopHjGTQxj
XM4SQIVdxAshW59zsmkcSIHCWR+Hqqfn0AEHde0x6YhNMp8WjETesvzamfIIM5r1
Wys6kEgz/DU=
=i+KC
-----END PGP SIGNATURE-----
References: