Diffie-Hellman (Dh) Key Groups; Perfect Forward Secrecy (Pfs); Ipsec Algorithms; Ah (Authentication Header) Protocol - ZyXEL Communications ZyWall 35 User Manual

ZyWALL 35 User's Guide

3.4.4.3 Diffie-Hellman (DH) Key Groups

Diffie-Hellman (DH) is a public-key cryptography protocol that allows two parties to establish
a shared secret over an unsecured communications channel. Diffie-Hellman is used within
IKE SA setup to establish session keys. 768-bit (Group 1 - DH1) and 1024-bit (Group 2 –
DH2) Diffie-Hellman groups are supported. Upon completion of the Diffie-Hellman
exchange, the two peers have a shared secret, but the IKE SA is not authenticated. For
authentication, use pre-shared keys.

3.4.4.4 Perfect Forward Secrecy (PFS)

Enabling PFS means that the key is transient. The key is thrown away and replaced by a brand
new key using a new Diffie-Hellman exchange for each new IPSec SA setup. With PFS
enabled, if one key is compromised, previous and subsequent keys are not compromised,
because subsequent keys are not derived from previous keys. The (time-consuming) Diffie-
Hellman exchange is the trade-off for this extra security.
This may be unnecessary for data that does not require such security, so PFS is disabled
(None) by default in the ZyWALL. Disabling PFS means new authentication and encryption
keys are derived from the same root secret (which may have security implications in the long
run) but allows faster SA setup (by bypassing the Diffie-Hellman key exchange).

3.5 IPSec Algorithms

The ESP and AH protocols are necessary to create a Security Association (SA), the
foundation of an IPSec VPN. An SA is built from the authentication provided by the AH and
ESP protocols. The primary function of key management is to establish and maintain the SA
between systems. Once the SA is established, the transport of data may commence.

3.5.1 AH (Authentication Header) Protocol

AH protocol (RFC 2402) was designed for integrity, authentication, sequence integrity (replay
resistance), and non-repudiation but not for confidentiality, for which the ESP was designed.
In applications where confidentiality is not required or not sanctioned by government
encryption restrictions, an AH can be employed to ensure integrity. This type of
implementation does not protect the information from dissemination but will allow for
verification of the integrity of the information and authentication of the originator.

3.5.2 ESP (Encapsulating Security Payload) Protocol

The ESP protocol (RFC 2406) provides encryption as well as some of the services offered by
AH. ESP authenticating properties are limited compared to the AH due to the non-inclusion of
the IP header information during the authentication process. However, ESP is sufficient if
only the upper layer protocols need to be authenticated.
88 Chapter 3 Wizard Setup