No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C10SPC500 Feature Description - Security 01

This is NE40E V800R010C10SPC500 Feature Description - Security
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
IKEv1 SA Negotiation Process

IKEv1 SA Negotiation Process

IKEv1 SA negotiation mainly consists of two phases.
  1. The purpose of IKEv1 phase-1 negotiation is to set up the IKE SA. After the IKE SA is set up, encryption and integrity check are performed on all ISAKMP messages between peers. The security channel ensures the security of IKEv1 phase-2 negotiation.

  2. IKEv1 phase-2 negotiation aims to establish IPsec SAs that are used for data transmission.

IKEv1 Phase-1 Negotiation

IKEv1 phase-1 negotiation mainly performs three tasks:

  1. Negotiation of the parameters used for setting up IKE SAs

    Parameters such as the encryption algorithm, authentication algorithm, authentication method and authentication key, DH group, and IKE SA lifecycle are defined in the IKE proposal.

  2. Exchange of key related information (materials used for key generation) using the DH algorithm

    Devices of the peers use the key materials to generate symmetric keys for ISAKMP message encryption and authentication.

  3. Mutual authentication between peers

    Peer devices authenticate each other using the pre-shared key or digital certificate.

After the three tasks are successfully negotiated, the IKE SA is set up.

IKEv1 phase-1 negotiation supports main mode and aggressive mode:

Main Mode

The main mode uses three steps to perform the preceding tasks. Each step requires two ISAKMP packets. Therefore six ISAKMP packets are required in total. The exchange of key-related information is performed before identity authentication. Therefore, the identity of the device is protected by the shared key.

In main mode, the procedure for IKEv1 phase-1 negotiation is shown in Figure 13-24.
Figure 13-24 IKEv1 phase-1 negotiation in main mode

The steps are described in details as follows:

  1. Negotiation of the IKE proposals used between peers

    1. Device A sends ISAKMP messages carrying parameters (defined by the IKE proposals) used for setting up the IKE SA.

    2. Device B negotiates with Device A about the IKE proposals.

      In the negotiation, proposals with higher priority are matched earlier. The negotiation succeeds only when at least one IKE proposal is matched. A proposal is matched if both ends use the same encryption algorithm, authentication algorithm, authentication method, and DH group identifier.

    3. Device B responds to the ISAKMP message with a packet that carries the matched proposal and parameters. If no proposal is matched, Device B rejects the proposals from the initiator.

  2. Exchange of key related information (materials used for key generation) using the DH algorithm and generation of keys

    1. The peers exchange key related information using two ISAKMP (numbered 3 and 4) messages.

    2. Four keys are generated using the key related information. SKEYID is the base key from which SKEYID_a, SKEYID_e, and SKEYID_d are derived. SKEYID_a is the key used for message integrity check, SKEYID_e is for ISAKMP message encryption, and SKEYID_d is for the derivation of encryption and authentication keys for IPsec packets.

      The SKEYID calculation formulate are different for the pre-shared key method and digital certificate method.

    Figure 13-25 DH exchange and key generation
  3. Mutual authentication between peers

    1. The peers exchange identity information using two ISAKMP messages (numbered 5 and 6). For the pre-shared key method, the identity information is the IP address or name. For the digital certificate method, the identity information also includes the content of the certificate. The identity information is encrypted using SKEYID_e, ensuring the security of the identity information.

    2. The peers use the encryption algorithm, authentication algorithm, identity authentication method, SKEYID_a, and SKEYID_e defined in the IKE proposal to perform encryption, decryption and authentication.

    IKEv1 supports the following identity authentication methods:

    • Pre-shared key

      This method requires that both ends have the same pre-shared key which is used in the calculation of SKEYID. For VPN networks that involve a small number of devices, the method is easy to configure. In large-scale VPN networks, the method is not recommended.

    • RSA signature (generally called digital certificate)

      Digital certificates are issued by CA servers. This method is suitable for large-scale dynamic VPN networks. The difference of the two methods lies in the calculation of SKEYID and the exchanged identity information. Other exchange and calculation procedures are the same.

    • Digital envelope

      In digital envelope authentication mode, an initiator encrypts data using the symmetric key. By encrypting the symmetric key using the public key of the asymmetric key, only a specified peer end is allowed to read the communication content, thereby determining the identity of the peer end.

      NOTE:

      The digital envelope authentication mode is applicable only to IKEv1 main mode.

Aggressive Mode

In aggressive mode, setting up an IKE SA requires on only the exchange of three messages.

In aggressive mode, the procedure for IKEv1 phase-1 negotiation is shown in Figure 13-26.
Figure 13-26 IKEv1 phase-1 negotiation in aggressive mode

The procedure for IKEv1 phase-1 negotiation in aggressive mode is as follows:

  1. Device A sends an ISAKMP message that carries the parameters used for setting up an IKE SA, information related to key generation, and identity authentication information.

  2. Device B confirms the first data packet it receives, searches for and sends the matched parameters, information used for key generation, and identity authentication information to Device A.

  3. Device A replies to the authentication result and sets up the IKE SA.

Compared with the main mode, the aggressive mode is more rapid in setting up IKE SAs. However, in aggressive mode, the identity cannot be protected because key exchange and identity authentication are carried out simultaneously.

Differences between the main mode and the aggressive mode

The aggressive mode does not provide identity protection, and is less secure than the main mode. The aggressive mode, however, can meet certain specific network requirements. For example:

  • During remote access, if the address of the initiator (terminal user) cannot be predicted by the responder (server) or is always changing, and both parties hope to apply the pre-shared key authentication to create an IKE SA, the aggressive mode can be adopted.

    NOTE:

    If the NE40E adopts the pre-shared key authentication mode, and the proxy IP address of the egress gateway can be obtained, the proxy IP address can be specified in main mode.

  • If the initiator knows or has an overall understanding of the policies of the responder, the aggressive mode can be applied to create an IKE SA more rapidly.

IKEv1 Phase-2 Negotiation

IKEv1 phase-2 negotiation is used to create IPsec SAs for data transmission. Figure 13-27 shows the relationship between the IPsec SA and IKE SA.
Figure 13-27 Relationship between the IPsec SA and IKE SA

IKEv1 phase-2 negotiation is completed through fast exchange. In fast exchange, SKEYID_a generated in IKEv1 phase-1 negotiation is used to implement integrity and identity authentication on ISAKMP messages, and SKEYID_e is used to encrypt ISAKMP messages, ensuring the security of the exchange.

In fast exchange, the peers negotiate the parameters of the IPsec SA and generate keys for data transmission.

Figure 13-28 shows the negotiation process in fast mode.

Figure 13-28 Process of IKEv1 phase-2 negotiation

Setting up an IPsec SA in fast exchange mode requires three messages.

  1. Message 1 sends the local security parameters and identity authentication information.

    Security parameters include the protected data flow and parameters that need negotiation such as the parameters of the IPsec proposal. Identity authentication information includes the keys calculated in IKEv1 phase-1 negotiation and the key materials generated in IKEv1 phase-2 negotiation which are used for the re-authentication of the peer.

  2. Message 2 sends the security parameters and identity authentication information of the responder in reply to message 1. In the process, a new key is generated.

    A new shared key is generated between the peers by exchanging key materials and an IPsec encryption key is derived. Then the initiator and responder each have two SAs.

    The encryption and authentication keys required in IPsec SA data transmission are derived from parameters such as SKEYID_d, SPI, and protocol, ensuring that each IPsec SA has a unique key.

    If Perfect Forward Secrecy (PFS) is enabled, the DH algorithm needs to calculate a shared key again to participate in the preceding calculation. Therefore, a DH key group needs to be negotiated for PFS during parameter negotiation.

  3. Message 3 responds to message 2 to confirm that the two ends can communicate. The negotiation finished.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055047

Views: 12704

Downloads: 31

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next