IPSec basics-Key Exchange and key protection Internet Key Exchange (IKE)

Internet Key Exchange (IKE)
Before the two IPSec computers exchange data, they must first establish an agreement called "Security Association ", both parties need to reach an agreement on how to protect information, exchange information, and other public security settings. More importantly, there must be a way for the two computers to securely exchange a set of keys, for use in their connections. See Figure 7.



Figure 7 Internet Key Exchange
IKE (Internet Key Exchange), The Security Association standard and key exchange solution developed by IETF, is responsible for these tasks, it provides a method for two computers to establish a security association (SA ). Sa encodes the policy protocols between two computers, specifying which algorithms and key lengths they will use, and the actual key itself. Ike has two main functions:

· Centralized management of security associations to reduce connection time
· Key generation and management
1. What is Sa?
Security Association SA (Security Association) is a one-way logical connection established between two entities (hosts or routers) using IPSec. It defines how security services (such as encryption) are used between entities) communication. It consists of the following elements: 1) security parameter index SPI; 2) IP destination address; 3) security protocol.

Sa is a one-way logical connection. That is to say, in one communication, IPSec needs to establish two SAS, one for inbound communication and the other for outbound communication. If a host, such as a file server or remote access server, needs to communicate with multiple clients at the same time, the server needs to establish different SA with each client. Each SA is identified by a unique SPI index. When receiving data packets, the server determines which SA to use based on the SPI value.

Ii. Phase 1 SA (Main Mode SA, Security Association for Channel Establishment)
Ike creates a SA in two stages. Phase 1: Create a communication channel (ike sa) through negotiation and authenticate the channel to provide the confidentiality, data integrity, and data source authentication services for further Ike communication. Phase 2, use an existing Ike SA to create an IPSec SA. Completing these services in two phases helps increase the speed of key exchange. Step 1:

1. Policy negotiation: In this step, negotiate the four mandatory parameter values:
1) encryption algorithm: Select des or 3DES
2) hash algorithm: Select MD5 or Sha
3) authentication method: Select certificate authentication, pre-shared key authentication, or Kerberos v5 authentication.
4) Selection of Diffie-Hellman Group
2. DH Switching
Although the name is "Key Exchange", in fact, no real key is exchanged between two communication hosts at any time, they exchange only the basic material information required by some Dh algorithms to generate shared keys. DH switching can be made public or protected. After the two hosts exchange keys to generate "Materials", the two hosts can generate the same shared "CMK" to protect the subsequent authentication process.

3. Authentication DH exchange requires further authentication. If the authentication fails, the communication will not continue. The "CMK" is used to authenticate the communication entity and channel based on the negotiation algorithm determined in step 1. In this step, the entire entity load to be authenticated, including the entity type, port number, and Protocol, is generated by the "Master Key" generated in the previous step to provide confidentiality and integrity assurance.

Iii. Phase 2 SA (fast mode SA, security association established for data transmission)
In this phase, an IPSec SA is established through negotiation to provide the IPsec service for data exchange. The second-stage negotiation message is protected by the First-stage SA. Any messages without the first-stage sa protection will be rejected.
Step 2:
1. Both parties exchange protection requirements through policy negotiation:
· Which IPSec protocol is used: Ah or ESP?
· Which hash algorithm is used: MD5 or Sha?
· Whether encryption is required. If so, select the encryption algorithm 3DES or des to reach an agreement on the above three aspects. Two SAS will be created for inbound and outbound communication respectively.
2. Refresh or exchange session key "material"
In this step, the "session key" of the encrypted IP packet is generated ". The material used to generate a "session key" can be the same or different from the "Master Key" in the first-stage SA. If you do not have special requirements, you only need to refresh the "material" and generate a new key. If different "Materials" are required, the second round of DH exchange is performed before the key is generated.

3. SA and key are submitted to the IPsec Driver together with SPI.
The second-stage negotiation process is similar to the first-stage negotiation process. The difference is that in the second stage, if the response times out, the first-stage SA negotiation is automatically re-performed.
In the first phase, the SA establishes a secure communication channel and stores it in the cache. On this basis, multiple second-stage SA negotiation can be established to speed up the establishment of the SA process. As long as the first-stage SA does not time out, there is no need to repeat the first-stage negotiation and authentication. The number of SA instances that can be created in the second stage is determined by the IPsec Policy attribute.

Iv. Sa Life Cycle
The first stage SA has a default validity period. If SA times out, or if any of the "Master Key" and "session key" expires, send the first-stage SA deletion message to the other party to notify the other party that the first-stage SA has expired. Then you need to re-negotiate with SA. The valid time of the second stage SA is determined by the IPsec Driver.

Key Protection
I. Key Life Cycle
The life cycle setting determines when a new key is generated. The process of re-generating a new key within a certain period of time is called "dynamic Key Update" or "key re-generation ". The key life cycle setting determines that a new key will be generated after a specific interval. For example, if one communication takes 10 thousand seconds, and the key life cycle is set to seconds, 10 keys will be generated throughout the data transmission. Using multiple keys in a single communication ensures that even if an attacker intercepts a single communication key, the security of all communications will not be compromised. The key life cycle has a default value, but both the "CMK" and "session key" can be modified through configuration. No matter which key expires, sa negotiation must be performed again. The maximum data volume that a single key can process cannot exceed 100 MB.

Ii. Session Key Update restrictions
Repeatedly generating materials from the same "CMK" to generate new "session keys" May cause key leaks. The "session key update restriction" function can effectively reduce the possibility of leakage. For example, after two hosts establish a Security Association, a first sends a message to B, and then sends another message to B after several minutes. Since the new SA was just created, the encryption keys used for the two messages may be generated using the same "material. To limit the number of times a key "material" is reused, you can set "session key update limit ". For example, if the "session key update limit" is set to 5, a maximum of five "session keys" can be generated for the same "material ".

If you enable "master key precise Forwarding (PFS)", the "session key update restriction" is ignored because PFS forces the use of new "material" to regenerate the key each time. Set "session key update restriction" to 1 and enable PFS. If both the "CMK" life cycle and the "session key update restriction" are set, no matter which condition is met first, a new round of SA negotiation is triggered. By default, IPSec does not set "session key update restrictions ".

Iii. Diffie-Hellman (DH) Group
The DH group determines the length of the Key Generation "material" in the DH exchange. The strength of the key depends on the DH group. Ike defines five DH groups. The length of the key "material" defined in group 1 (low) is 768 bits, and the length of group 2 (medium) is 1024 bits. The longer the key "material" length, the higher the security of the generated key, and the harder it is to be decrypted.

The selection of DH groups is very important, because DH groups are determined only in the SA negotiation of the first stage. The DH group is not re-selected in the negotiation of the second stage. The two stages use the same DH group, therefore, the selection of this DH group affects the generation of all "session keys.

During the negotiation process, the same DH group should be selected for peer entities, that is, the length of the key "material" should be equal. If the DH group does not match, negotiation fails.
Iv. Precise forwarding and confidentiality PFS (perfect forward secrecy)
Unlike the key life cycle, PFS determines the generation method of the new key, rather than the generation time of the new key. PFS ensures that a key can only be used once at any stage, and the "material" for generating the key can only be used once. After a "material" is generated into a key, it is discarded and no other key is generated. This ensures that, once a single key is disclosed, only data encrypted with the key may be affected at most, without compromising the entire communication.

PFS is divided into "master key" PFS and "session key" PFS. When "master key" PFS is enabled, Ike must re-authenticate the communication entity, that is, one Ike SA can only create one IPSec SA, for each second-stage SA negotiation, the "Master Key" PFS requires a new first-stage negotiation, which will incur additional system overhead. Therefore, be especially careful when using it.

However, enabling "session key" PFS does not require re-authentication, so it requires less system resources. "Session key" PFS only requires a new DH exchange for the new key generation, that is, four additional messages need to be sent, but no re-authentication is required. PFS does not belong to the negotiation attribute and does not require both parties to enable PFS at the same time. Both the "CMK" PFS and "session key" PFS can be set independently.