IPSec base-key exchange and key protection Internet Key Exchange (IKE)

Internet Key Exchange (IKE)
Before exchanging data between two IPSec computers, a convention must be established first, a convention called a "security association", in which both parties need to agree on how to protect the information, exchange information, and other common security settings, and 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 Seven.

Figure VII, Internet Key exchange
Internet Engineering Task Group IETF Security Association standard method and key exchange solution--ike (Internet Key Exchange) is responsible for these tasks, which provide a way for two computers to establish a security association (SA). The SA encodes the policy protocols between the two computers, specifying which algorithms they will use and what key lengths, and the actual key itself. IKE mainly accomplishes two functions:
• Centralized management of security associations to reduce connection time
• Key generation and management
One, what is SA.
A secure Association SA (Security Association) is a one-way, logical connection between two entities that use IPSec (a host or router) that defines how an entity uses security services, such as encryption, to communicate. It consists of the following elements: 1 security Parameter index SPI;2) IP destination address; 3 security protocol.
An SA is a one-way logical connection, that is, in one communication, IPSEC needs to establish two SAS, one for inbound traffic and the other for outbound traffic. 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 separate SAS with each client. Each SA is identified with a unique SPI index, and when processing the receiving packet, the server determines which SA to use based on the SPI value.
Second, Phase I SA (main mode SA, security association for establishing a channel)
IKE establishes the SA in two phases. In the first phase, negotiate the creation of a communication channel (IKE SA) and authenticate the channel to provide confidentiality, data integrity, and data source authentication services for further IKE communications between the two parties; in the second phase, an IPSec SA is established using an established IKE SA. Completing these services in two phases helps to increase the speed of key exchange. First-stage negotiation (main mode negotiation) step:
1. Policy negotiation, in this step, the four mandatory parameter values are negotiated:
1 encryption algorithm: Select des or 3DES
2 Hash algorithm: select MD5 or Sha
3 Authentication method: Select certificate authentication, preset shared key authentication or Kerberos V5 authentication
4) Selection of Diffie-hellman Group
2. DH Exchange
Although the name is "key Exchange", in fact, at any time, the two communication hosts do not exchange real keys, they exchange only some of the DH algorithm to generate the shared key information required by the basic materials. DH Exchange, can be public or protected. After exchanging key generation "material", each host can generate identical shared "master key" to protect the authentication process immediately thereafter.
3. Certification DH Exchange needs to be further authenticated, if the authentication is unsuccessful, communication will not continue. The master key is used to authenticate the communication entity and communication channel by combining the negotiation algorithm defined in the first step. In this step, the entire entity payload to be certified, including entity types, port numbers, and protocols, provides confidentiality and integrity guarantees from the "master key" generated in the previous step.
Phase II SA (quick mode SA, security association established for data transfer)
This phase negotiates the establishment of IPSec SAS and provides IPSec services for data exchange. The second phase of the negotiation message is protected by the first stage SA, and any messages without the first phase SA protection will be rejected.
Phase II Negotiation (Quick mode negotiation) steps:
1. Policy negotiation, mutual exchange protection requirements:
• What type of IPSec protocol is used: AH or ESP
• What kind of hash algorithm is used: MD5 or Sha
• Whether to require encryption, if, select the encryption algorithm: 3DES or des in the above three areas of agreement, will establish two SAS, respectively for inbound and outbound traffic.
2. Session key "material" refresh or swap
In this step, the session key for encrypting IP packets is generated. The material that is used to generate the session key can be the same as or different from the master key in the first stage SA generation. If you do not make a special request, only need to refresh the "material", generate the Xinmi key. If a different "material" is required, the second round of the DH Exchange is performed before the key is generated.
3. The SA and the key, along with the SPI, are submitted to the IPSec driver.
The second phase of the consultation process is similar to the first phase of the negotiation process, except that in the second phase, if the response times out, an automatic attempt is made to reopen the first phase of SA negotiation.
The first phase SA establishes a secure communication channel and is stored in the cache, on the basis of which several second-stage SA negotiations can be established to increase the speed of the entire build up of the SA process. As long as the first phase SA does not time out, you do not have to repeat the first phase of negotiation and authentication. The number of second stage SAS that are allowed to be established is determined by the IPSec policy attribute.
Iv. life cycle of SA
The first phase SA has a default valid time, and if the SA times out, or any one of the lifetime time in the master key and session key, sends the first phase SA delete message to the other side to notify each other that the first stage SA has expired. You will then need to restart the SA negotiation. The valid time for the second stage SA is determined by the IPSec driver.
Key protection
One, Key life cycle
The lifetime setting determines when the Xinmi key is generated. The process of regenerating the XINMI key at a certain interval is known as "Dynamic key Update" or "key regeneration." The key life-cycle setting determines that the Xinmi key is forced to be generated after a specific time interval. For example, assuming that a communication takes 10,000 seconds and we set the key lifetime to 1000 seconds, 10 keys will be generated during the entire data transfer. Using multiple keys in one communication ensures that even if an attacker intercepts a single communication key, the entire communication security is not compromised. The key lifetime has a default value, but both the master key and session key lifetimes can be modified by configuration. The SA negotiation is restarted regardless of the key lifetime time. The maximum amount of data that a single key can handle does not allow more than 100 megabytes.
Second, session key update restrictions
Repeatedly generating material from the same "master key" to generate a new "session key" is likely to result in key leaks. The session key update limit feature can effectively reduce the likelihood of leaks. For example, after two hosts establish a security association, a first sends a message to B, and a few minutes later sends another message to B. Since the new SA was newly established, the encryption key used for both messages is likely to be generated with the same "material". If you want to limit the number of times a key "material" is reused, you can set the session key update limit. For example, setting the session key update limit to 5 means that the same material can generate up to 5 session keys.
When master key exact forward secrecy (PFS) is enabled, session key update restrictions are ignored because PFS forces new "material" to regenerate the key each time. Setting the session key update limit to 1 and enabling the PFS effect is the same. If both the master key lifetime and the session key update limit are set, a new round of SA negotiation is raised regardless of which constraint is met first. By default, IPSec does not set the session key update limit.
Iii. Diffie-hellman (DH) group
The DH group determines the length of the key generation "material" in the DH exchange. The firmness of the key is partly determined by the strength of the DH group. IKE has a total of 5 DH groups defined, and Group 1 (low) defines a key "material" length of 768 bits, and a group 2 (medium) length of 1024 bits. The longer the key "material" is, the greater the security of the key generated, and the more difficult it is to decipher.
The selection of the DH group is important because the DH group is determined only in the first phase of the SA negotiation, the second phase of the negotiation no longer selects the DH group, the two phases use the same DH group, so the selection of the DH group affects the generation of all session keys.
During the negotiation process, the same DH group should be selected between the peers, i.e. the key material should be equal in length. If the DH group does not match, it is considered a negotiation failure.
Iv. accurate forwarding of confidential PFS (Perfect Forward secrecy)
Unlike key lifetimes, PFS determines how Xinmi keys are generated, not when new keys are generated. PFS guarantees that a key can only be used once in any phase, and that the material that generates the key can only be used once. A "material" is discarded when it generates a key, and is never used to regenerate any other key. This ensures that once a single key is compromised, it can only affect data encrypted with that key without compromising the entire communication.
PFS is divided into "master key" PFS and "session key" PFS, enable master key Pfs,ike must authenticate the communication entity, that is, an IKE SA can only create one IPSec SA, and for each second phase of SA negotiation, master key PFS requires a new first-stage negotiation. This will result in additional system overhead. So use it with extra care.
However, session key PFS can be enabled without having to be authenticated and therefore less required for system resources. Session key PFS only requires a new DH exchange for Xinmi key generation, that is, four additional messages need to be sent, but no authentication is required. PFS is not part of the negotiation attribute and does not require both sides of the communication to open PFS at the same time. Both master key PFS and session key PFS can be set independently.