When using IKE dynamic negotiation to establish an IPSec tunnel, there are two types of SA: one is IKE SA and the other is IPSec SA. The purpose of establishing IKE SA is to negotiate a set of security parameters used to protect IPSec tunnels. The purpose of establishing IPSec SA is to negotiate security parameters used to protect user data. However, in IKE dynamic negotiation mode, IKE SA is the basis of IPSec SA. , because the establishment of IPSec SA requires a series of keys after the IKE SA is established.
Manually establishing an SA has the disadvantages of complex configuration, not supporting dynamic changes of the initiator address, the established SA never aging, and being detrimental to security. This section details the benefits of dynamic negotiation and the relationship between IKE and IPSec.
(1) Reduces the complexity of configuration. In IKE dynamic negotiation mode, parameters such as SPI, authentication key and encryption key will be automatically generated, while in manual mode, parameters such as the outgoing and incoming direction of the SA need to be generated automatically. Directions are specified separately.
(2) Provide anti-replay function. IPSec uses the sequence number in the AH or ESP header to implement anti-replay (packets with the same sequence number are not accepted). When the sequence number in the AH or ESP header overflows (it also reaches the maximum value and cannot continue to be numbered, and a new round of renumbering begins), in order to achieve anti-replay, the SA needs to be re-established. This process requires In conjunction with the IKE protocol, the anti-replay function is not supported in manual mode.
(3) Supports identity authentication when the address of the negotiation initiator changes dynamically (such as using PPP.E dial-up mode to access the Internet). The manual method is not supported and can only be applied to dedicated lines at both ends. The connection method is to access the Internet.
(4) Support the online authentication and centralized management of peer identities by the certification center CA (Certificate Authority), which is conducive to large-scale deployment of IPSec. The manual method does not support online authentication.
(5) The SA established through IKE negotiation has a life cycle and can be updated in real time, which reduces the risk of SA being cracked and improves security.
When the life cycle reaches the specified time or the specified traffic, the SA will become invalid. Before the SA is about to expire, IKE will negotiate a new SA for the peer. After the new SA is negotiated, the peer immediately adopts the new SA to protect communications. There are two ways to define the life cycle:
The IKE protocol is based on the framework defined by ISAKMP (Internet Security Association and Key Management Protocol) and is an application layer based on UDP. Protocol (corresponding to UDP500 port. It provides IPSec with automatic negotiation key exchange and SA establishment services, which can simplify the use and management of IPSec.
In fact, IKE is not a separate protocol, it includes three major Protocol: ISAKMP (Internet Security Association and Key Management Protocol, Internet Security Alliance and Key Management Protocol), Oakley (Oakley Key Determination Protocol, Oakley Key Determination Protocol) and SKEME (Secure Key Exchange Mechanism for Internet, Internet Security Key Key exchange mechanism). ISAKMP mainly defines the cooperative relationship between IKE peers and establishes IKE SA. The OakLey protocol is a framework for generating and exchanging IPSec key materials and coordinating IPSec parameters (including which security protocols are supported). ; The SKEM E protocol determines the IKE key exchange method, mainly using the DH (Diffie-Hellman) algorithm.
The relationship between IKE and IPSec (including AH and ESP protocols) is shown in the figure below. IKE is UDP. An application layer protocol above (AH and ESP are network layer protocols) is the signaling protocol of IPSec; IKE establishes an SA for IPSec negotiation and hands over the established parameters and generated keys to IPSec; IPSec is established using IKE SA encrypts or authenticates IP packets.
After an IKE SA is established between peers, when the IKE SA protects the IPSec tunnel, the SA will encrypt or authenticate IP packets according to the configured AH, ESP security protocol and other parameters. Negotiate a pair of IPSec SAs for secure data transmission in the IPSec tunnel.
The IKE protocol currently has two versions: IKEv1 and IKEv2. The IKEv1 version uses IPSec. Perform key negotiation and finally establish IPSec SA. In the first stage, the communicating parties negotiate to establish a secure channel (ie, tunnel) used by IKE itself, that is, to establish a pair of IKE SA.
In the second stage, this secure channel that has passed authentication and security protection is used to establish a pair of IPSec SAs to protect the secure transmission of data in the tunnel. The IKEv2 version simplifies the negotiation process and can directly generate IPSec keys and IPSec SAs in one negotiation.
Let’s first understand some of the security mechanisms used by IKE in the process of generating SA (including IKE SA and IPSec SA), which will be used later in the specific IKE negotiation process.
The important reason why IPSec application solutions can securely conduct network communications on public networks (such as the Internet) is that various security measures can be implemented during the entire tunnel establishment and data transmission process between peers. Security mechanism is used to ensure this. If IKE is used for automatic key exchange and negotiation, it can also be done, because IKE itself has a complete set of self-protection mechanisms that can safely authenticate identities on insecure networks. Distribute keys. This is specifically reflected in the following aspects of security protection.
When using IKE to exchange information between peers, you must first identify the legitimacy of the other party, which is an identity authentication issue. The mechanisms that can be used to determine the peer identity (peer's IP address or name) in IKE are relatively comprehensive, including pre-shared key PSK (pre-shared key) authentication, RSA digital certificate (rsa-signature, Or called RSA digital signature) authentication and RSA digital envelope authentication.
In a digital envelope, the sender uses a symmetric key (the sender needs to randomly generate a symmetric key in advance) to digitally sign the message to be sent, and then uses the symmetric key with the receiver After encrypting with the public key (this part is called a digital envelope), the encrypted symmetric key is sent to the recipient together with the digitally signed message. After receiving it, the recipient first uses its own private key to open the digital envelope to obtain the sender's symmetric key, and then uses the symmetric key to decrypt the original digitally signed message to verify whether the sender's digital signature is correct. If correct, the authentication passes; otherwise, the authentication fails.
For the pre-shared key authentication method, when there is one peer corresponding to multiple peers, a pre-shared key needs to be configured for each peer. The amount is large, so this method is easy to establish in small networks, but it is less secure. Using digital certificates has high security, but requires a CA to issue digital certificates, which is suitable for use in large networks. Digital envelope authentication is used when the device needs to comply with the requirements of the National Cryptographic Administration (it needs to use the hash algorithm SM3 required by the National Cryptographic Administration), and this authentication method can only be supported during the main mode negotiation process of IKEv1.
The various keys used for identity authentication mentioned above are all IKE authentication keys. The supported algorithms are: MD5, SHA1, SHA2-256, SHA2-384, SHA2-512, SM3 . The MD5 algorithm uses a 128-bit key, the SHA-1 algorithm uses a 160-bit key, SHA2-256, SHA2-384, and SHA2-512 use 256-bit, 384-bit, and 512-bit keys respectively, and SM3 uses a 128-bit key. . The order of security from high to low is: SM3>SHA2-512>SHA2-384>SHA2-256>SHA1>MD5. For ordinary security requirements, it is recommended to use SHA2-256, SHA2-384 and SHA2-512 as authentication algorithms. MD5 and SHA1 are not recommended. For places with particularly high security requirements, the SM3 algorithm can be used.
The identity authentication keys (including pre-shared keys, public/private keys) and certificates involved above are all used as the "verification data" of the sender and must be sent to the other party through the corresponding method. Verified.
IPSec’s data encryption mechanism is mainly used in two aspects: First, during the IKE negotiation phase, it protects the transmitted data information (such as shared keys, certificates, authentication keys, etc.) used for identity authentication. key, etc.), and the second is to protect user data transmitted in the tunnel after the IPSec tunnel is established. But the symmetric key mechanism used in the data encryption mechanism mentioned here means that the same key is used for encryption and decryption, rather than the asymmetric key system used in digital certificate authentication and digital signature applications introduced earlier.
The encryption algorithms supported by IKE include: DES, 3DES, AES-128, AES-192, AES-256, SM1 and SM4, etc. The DES algorithm uses a 56-bit key, 3DES uses a 168-bit key, AES-128, AES-192, and AES-256 use 128, 192, and 256-bit keys respectively, and both SM1 and SM4 use 128-bit keys.
The order of security levels of these encryption algorithms from high to low is: SM4 > SMI1 > AES-256 > AES-192 > AES-128 > 3DES > DES. It is recommended to use AES-256, AES-192 and AES-128, not recommended. Using 3DES and DES algorithms, SM1 and SM4 are only recommended in places with very high confidentiality and security requirements because their operation speeds are relatively slow. The RSA or DSA (Digital Signature Algorithm, digital signature algorithm) encryption algorithm is usually used in asymmetric key systems.
The Diffie-Hellman algorithm is a public key algorithm. The two communicating parties can calculate the key shared by both parties by only exchanging some data without transmitting the key. And it can be done that even if a third party intercepts all exchange data used by both parties to calculate the key, it is not enough to calculate the real key.
DH is mainly used to regenerate the key used in the new IPSec SA during IKE dynamic negotiation, because it can finally calculate the key shared by both parties through a series of data exchanges without Rely on the key generation material generated in the previous stage. However, DH does not provide any information about the identities of both parties and cannot determine whether the exchanged data is sent to the legitimate party. The third party can use the intercepted data to negotiate the key with both communicating parties and enjoy the communication, thereby obtaining and transmitting information, so IKE Identity authentication is also required to authenticate the identity of the peer.
PFS (Perfect Forward Secrecy, perfect forward security) is a security feature that means that after one key is cracked, it does not affect the security of other keys because there is no derivation between these keys. relation.
As you can see from the introduction later in this chapter, the IPSec SA key is derived from the IKE SA key. Since an IKE SA negotiation can generate one or more pairs of IPSec SAs that have a certain derivation relationship, when the IKE key is stolen, the attacker is likely to illegally derive the IPSec SA key by collecting enough information, so that It's not safe anymore. If PFS is enabled during the IPSec generation phase, a new, independent IPSec SA can be generated by performing an additional DH exchange, thus ensuring the security of the IPSec SA key.
As mentioned above, the IKEvl version needs to go through two stages to generate the final IPSecSA, which are used to establish IKESA and IPSecSA respectively. This section first introduces the first stage.
The ultimate goal of the first phase of IKEvl is to create a secure channel between peers and establish IKESA of the peers. In this phase, IKE peers authenticate each other and determine the same session key. At this stage, the Diffie-Hellman (DH) algorithm needs to be used to exchange keys and complete the establishment of IKE SA, so that the negotiation process in the second stage can be securely protected.
In the IKEvl version, the process of establishing IKE SA has two exchange modes: Main Mode and Aggr essive Mode (also called "aggressive mode"). They are introduced separately below.
The establishment process of IKE SA in main mode of IKEv1 includes three bidirectional message exchanges and uses six pieces of information. The exchange process is shown in the figure.
These six messages are actually three steps in total, each containing two adjacent numbered messages.
The first step corresponds to messages ① and ②, which is when the peers at both ends of the tunnel negotiate the IKE security policy to be adopted by exchanging the IKE policies configured with each other, because only two parties Only by adopting the same security policy can they identify each other's encrypted data and correctly authenticate each other's identity.
The second step corresponds to messages ③ and ④, which are the parameter information required for key generation between peers through the DH algorithm (DH public value and random number nonce, etc.), establishing A series of shared keys that are the same at both ends, mainly including the identity authentication key used for negotiation in the second phase and the encryption key for negotiation data.
The third step corresponds to messages ⑤ and ⑥, using the previously created encryption keys to send each other their respective identities (such as the IP address or name of the peer) and verification data (used Key in the identity authentication method, or certificate data, etc.), use the corresponding authentication method to perform identity authentication between peers. Finally, the establishment of IKE SA is completed.
Before formally exchanging messages, the initiator and receiver must first calculate their respective cookies (in the ISKMP header to prevent replay and DoS attacks). These cookies are used to identify each individual Negotiate and exchange messages. The RFC recommends hashing the source/destination IP address, source/destination port number, locally generated random number, date and time to generate a cookie.
The cookie becomes the unique identifier for the information exchanged in the IKE negotiation. In the IKEv1 version, it is Cookie. In the IKEv2 version, the Cookie is the SPI (Security Parameter Index) of IKE.
The following is a detailed introduction to the six messages mentioned above.
As shown in the figure, aggressive mode only uses three pieces of information. Messages ① and ② are used to negotiate IKE security policies between peers, exchange DH public keys, necessary auxiliary information and identity information (usually Not identified by IP address, but by host name).
From the comparison between aggressive mode and main mode, it can be found that compared with main mode, aggressive mode reduces the number of exchanged information and increases the speed of negotiation, but does not encrypt identity information and verification data. , because the identity information sent by both parties (corresponding to the ① and ② messages) is not encrypted (but the identity information and verification data sent in the main mode are encrypted, corresponding to the ⑤ and ⑥ messages). Although aggressive mode does not provide identity protection, it can still meet the needs of certain network environments.
When there is a NAT device in the IPSec tunnel, the NAT traversal function needs to be enabled, and NAT conversion will change the IP address of the peer. Since the aggressive mode does not rely on the IP address to identify the identity, if pre-* **When using the shared key verification method, NAT traversal can only be achieved in aggressive mode. If the initiator's P address is not fixed or unpredictable, and both parties want to use the pre-shared key verification method to create an IKE SA, they can only use aggressive mode.
If the initiator knows the responder's policy, or has a comprehensive understanding of the responder's policy, aggressive mode can be used to create an IKE SA faster.
ikev1 version 1 The second stage is to finally establish a pair of SAs based on the first stage. It has only one mode, Quick Mode. The negotiation in fast mode is protected by SA, and the entire negotiation process is shown in the figure.
During the negotiation process in fast mode, the following IPSec security policies are mainly determined:
After reaching agreement on the above aspects, two PSec SAs will be established, respectively. Inbound and outbound communications.
The IPSec security proposals in messages ① and ② include security protocols, spi, IPSec encapsulation mode, PfS (optional), IPSec SA life cycle, etc. These two messages also include the identity information of both parties (such as IP address, transport layer port), verification data (including keys, certificates, etc. in the identity authentication mechanism used), and nonce (a random number, used to resist Replay, also used as password generation material, only used when PFS is enabled). The receiver will use the received data from the other party to generate an encryption key. Message ③ is a confirmation message. By confirming that the sender has received message ② at this stage, the responder knows that formal communication is possible.
IKEv1 needs to go through two stages and exchange at least 6 messages before finally establishing a pair of PSec SAs. However, IKEv2 reduces the number of information transmitted and exchanges while ensuring security, making it easier to implement. Simple.
IKEv2 retains most of the features of IKEv1, and some extended features of IKEv1 (such as NAT traversal) are introduced into the IKEv2 framework as an integral part of the IKEv2 protocol. Different from IKEV1, all messages in IKEv2 appear in pairs in the form of "request-response". The responder must confirm the message sent by the initiator. If the confirmation message is not received within the specified time, the initiator needs to The message is retransmitted to improve security.
IKEv2 can also defend against DoS attacks. In IKEv1, when the attacker in the network keeps replaying the message, the responder needs to respond to it after calculation, which consumes device resources and causes a DoS attack on the responder. In KEv2, after receiving the request, the responder is not in a hurry to calculate, but first sends a cookie type Notify payload (i.e. a specific value) to the initiator. The subsequent communication between the two must maintain the relationship between Fcookie and the initiator. The corresponding relationship between them effectively prevents DoS attacks.
IKEv2 defines three exchange types: Initial Exchanges (InitialExchanges), Create Child SA Exchange (Create _Child _SA Exchange) and Notification Exchange (InformationalExchange). IKEv2 can complete the negotiation and establishment of an IKE SA and the first pair of IPSec SA through initial exchange. If more than one pair of IPSec SAs are required to be established, each pair of IPSec SA values ??only needs to be added once to create a sub-SA exchange (and if IKEv1 is used, the creation of sub-SA still needs to go through two stages).
The initial exchange of IKEv2 corresponds to the first phase of IKEv1. The initial exchange includes two exchanges of four messages, as shown in the figure.
Messages ① and ② belong to the first exchange. They complete the parameter negotiation of IKE SA in plain text. They mainly negotiate encryption algorithms, exchange nonce values, and complete a DH exchange to generate key materials for encryption and verification of subsequent exchanges. Messages ③ and ④ belong to the second exchange, which completes identity authentication in an encrypted manner (by exchanging identity information and verification data), authentication of the first two pieces of information and parameter negotiation of IPSec SA.
After the initial exchange is completed, any party can initiate the creation of a sub-SA exchange. The initiator in this exchange may be different from the initiator in the initial exchange. This exchange must occur after the initial exchange has been completed, and the exchange messages are protected by the keys negotiated in the initial exchange.
The Create Sub-SA exchange contains two messages, which are used for one IKE SA to create multiple IPSec SAs or IKE renegotiation, corresponding to the second phase of IKEv1. If you need to support PFS, create a sub-SA exchange and perform an additional DH exchange to establish a new key that dares to establish an IPSEC SA.
During the key negotiation between the communicating parties, one party may want to send control information to the other party to notify the occurrence of certain errors or events, which needs to be completed by the "notification exchange process."
Notification exchange, as shown in Figure 2-15, is used to transmit some control information between peers, such as error information, deletion messages, or notification information. The party receiving the information message must respond, and the response message may not contain information. Contains any payload. The notification exchange can only occur after the initial exchange, and its control information can be of the IKE SA (the exchange is protected by IKES A) or of the sub-SA (the exchange is protected by the sub-SA).