Both sides agree on the cryptographic algorithms to be used for encryption and data signing when establishing a connection. The algorithms can be configured separately for each phase. In the Intra2net system, encryption profiles with algorithms can be configured in the "" menu.
An encryption method consists of an encryption algorithm, a hashing (signature) algorithm, and a Diffie-Hellman group for establishing session keys. Most algorithms are available in different lengths. The length is specified in bits, and the more bits used, the stronger the algorithm. However, the computational effort required also increases with the number of bits.
In IKEv2, depending on the chosen algorithm, the pseudo-random function (PRF) and the integrity check value (ICV) are also added.
Some encryption functions can encrypt and sign simultaneously, which is called Authenticated Encryption with Associated Data (AEAD). This provides protection against certain classes of attacks that target the difference between encryption and signing, as well as advantages in data throughput and required computing power. These methods are therefore to be preferred.
Normally, the same function is automatically used for signature and pseudo-random function. Since no separate signature algorithm is used with AEAD, the pseudo-random function (PRF) must now be explicitly selected.
For both phases, or types of Security Associations (SA) in IKEv2, a list of possible methods is now stored. This list is presented to the peer in the specified order, and the peer then uses the first method on the list that it also supports.
All configured encryption methods / algorithm combinations are transmitted to the peer during connection establishment. It is common that not an arbitrary number of different algorithm combinations are accepted. The exact number depends on the implementation of the IKE service. Usual limits for the accepted number of algorithm combinations per phase, or per type of Security Association (SA) in IKEv2, are between 10 and 25.
Therefore, make sure not to configure too many different encryption methods / algorithm combinations in an encryption profile.
In IKE, a session key is always agreed upon using the Diffie-Hellman method before authentication. The exception to this is the Aggressive Mode of IKEv1, which is therefore considered insecure and is intentionally not offered by the Intra2net system. The session keys for transmitting user data can be derived directly from this session key.
Perfect Forward Secrecy (PFS) in the context of IPSec means that the session keys for user data are not derived directly from the IKE session key, but new, independent session keys are agreed upon. If, for some reason, the session key of the IKE connection becomes known, the protection of the user data transmitted so far is maintained through PFS.
However, since the IKE connection and its session keys are normally renewed automatically after a few hours, Perfect Forward Secrecy for IPSec is clearly recommended but not absolutely necessary. This is a clear difference from other protocols such as TLS, where the protection of user data without PFS depends directly on the very long-lived key of the certificate and the use of PFS is therefore essential.
If a PFS group for Phase 2 is specified on the Intra2net system, it is proposed to the peer during connection establishment. Only a single PFS group for Phase 2 can be proposed, not a list of combinations as with encryption and signature algorithms.
If the peer establishes the connection and a PFS group is configured, it depends on the "Always accept proposed PFS group" option whether the Intra2net system insists on the configured group or accepts all proposed by the peer.
If the PFS group is set to None, connections are established without PFS. If the peer establishes the connection, connections with any PFS group and without PFS are accepted.
PFS is selected in IKEv2 via the "Diffie Hellman Group" option for the data tunnel (CHILD_SA). The option is offered to the peer as part of the combination of encryption and signature algorithms and must be accepted by it. There is no special treatment of this parameter as in IKEv1 (see above).
The first establishment of a CHILD_SA always takes place simultaneously with the IKE_SA and authentication, and at this moment the negotiation of the session keys is protected by the Diffie-Hellman key agreement that took place immediately before. Therefore, no additional key agreement via the Diffie-Hellman method is required during the first establishment of a CHILD_SA.
This is different for later renewals of CHILD_SAs. If Perfect Forward Secrecy is desired here, a further Diffie-Hellman key agreement is necessary. If both sides disagree on whether and with which algorithm this should be done in the configuration, the renewal of the CHILD_SA may fail and, as a result, the connection may be interrupted.