IKE Overview AND Ipsec Working PDF

Preview

Summary

IKE negotiates with IPSec security organizations (SAs). This process requires IPSec systems to first authenticate themselves and establish ISAKMP, or IKE, shared keys....

Description

SRM INSTITUTE OF SCIENCE AND TECHNOLOGY KATTANKULATHUR NETWORK SECURITY 20CSE625J IKE OVERVIEW AND IPSEC WORKING

IKE Overview

IKE negotiates with IPSec security organizations (SAs). This process requires IPSec systems to first authenticate themselves and establish ISAKMP, or IKE, shared keys. In the first phase, IKE creates a certified secure channel between two IKE peers called the IKE Security Association. The Diffie-Hellman key agreement is always made at this stage. In the second phase, IKE negotiates with IPSec security organizations and produces the necessary IPSec requirements. The sender provides one or more conversion sets used to specify an approved combination of modifications and settings. The sender also indicates the data flow to be used for the conversion set. The sender must provide at least one conversion set. The recipient then returns one set of changes, indicating the agreed changes and algorithms for this particular IPSec session. A new Diffie-Hellman contract can be made in the second phase, or the keys can be found in the first phase of the shared secret.

NOTE A security organization (SA) is a relationship between two or more businesses that describes how businesses will use security services to communicate

securely. SAs are discussed in more detail later in this chapter under the heading "IPSec Security Associations".

IKE function IKE verifies peer and IKE messages among peers during the first phase of IKE. The first category contains main mode or aggressive mode. Peers who may be in the IPSec session should confirm each other before IKE can proceed. Peer verification occurs during the main mode exchange during the first phase of IKE. The IKE protocol is very flexible and supports multiple authentication methods as part of the first phase exchange. The two businesses must agree on a similar verification protocol through the negotiation process. The first phase of IKE has three ways to authenticate IPSec peers in Cisco products, which are as follows: • Pre-allocated keys — A personalized key in the peer-to-peer (excluding band) used to verify peer authenticity • RSA Signatures — Use a digital certificate validated by the RSA signature • RSA encrypted nonces — Use RSA encryption to encrypt nonce value (random number by peers) and other values The most common value used by all means is peer identity verification (ID), which helps to identify peers. Some of the ID numbers used are as follows: • Peer-to-peer IP address (four octets), such as 172.30.2.2 • Fully qualified domain name (FQDN), such as [email protected]

Pre-Shared Keys

With pre-shared keys, the same pre-shared key is adjusted for each IPSec peer. IKE peers confirm computer simulation and send a hash key with data key including pre-shared key. If the recipient is able to create the same hash independently using the pre-allocated key, you know that both peers must have the same secret, thus securing another peer. Pre-allocated keys are easier to set up than to set IPSec policy values for each IPSec peer. However, pre-

allocated keys do not fit well because each IPSec peer must be pre-configured with a pre-allocated key for every other peer to establish time.

RSA signatures

The RSA signature method uses a digital signature, in which each device signs a set of data and sends it to another group. RSA signatures use CA to generate a unique digital ID that is issued to each of your peers for verification. Digital ID certification is the same as work on a pre-shared key, but it offers much stronger security. RSA is a public key cryptosystem used by IPSec to authenticate phase 1 IKE. RSA was developed in 1977 by Ronald Rivest, Adi Shamir, and Leonard Adelman. The developer and respondent to the IKE session using RSA signatures submit their ID value (ID, IDr), their digital ID certificate, and the RSA signature number incorporating various IKE values, all encrypted in the IKE encrypted negotiation method (DES or 3DES).

RSA encryption

The RSA-encrypted nonces method uses the encryption key for the RSA public key. The method requires each party to generate a non-fake number and encrypt the RSA public key of another component. That is to say, either side of the exchange could clearly deny its involvement in the trade. Cisco IOS software is the only Cisco product that uses RSA encrypted nonces to authenticate IKE. RSA encrypted nonces use the RSA public key algorithm.

CAs and Digital Certificates

Distribution of keys to a public key scheme requires some trust. If infrastructure is unreliable and controls are in doubt, as with the Internet, key distribution is a problem. RSA signatures are used by CAs, which are trusted third party organizations. Verisign, Entrust, and Netscape are examples of companies that provide digital certifications. To obtain a digital certificate, the client registers with the CA. After the CA verifies client credentials, a certificate is issued. A digital certificate is a package containing information such as the certificate holder's identity: name or IP address, certificate product number, expiration date of the certificate, and a copy of the public key holder of the certificate. The standard digital certificate format is defined in specifics X.509. The X.509 version 3 describes the structure of the certification data and is a standard supported by Cisco that identifies certain key performance points for CA.

How IPSec works IPSec incorporates multi-component technology and encryption methods. However IPSec performance can be divided into five key steps. The five steps are summarized as follows. Step Interesting traffic initiates the IPSec process—Traffic is deemed 1 interesting when the IPSec security policy configured in the IPSec peers starts the IKE process. Step IKE phase one—IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec 2 SAs in phase two.

Step IKE phase two—IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers. 3 Step Data transfer—Data is transferred between IPSec peers based on the 4 IPSec parameters and keys stored in the SA database. Step IPSec tunnel termination—IPSec SAs terminate through deletion or 5 by timing out. This five-step process is shown

The Five Steps of IPSec

Step 1: Defining Interesting Traffic Determining which type of traffic is considered interesting is part of formulating a security policy for VPN use. The policy is then applied to the visual configuration interface for each IPSec peer. For example, in Cisco and PIX Firewalls routers, access lists are used to determine the traffic to be encrypted. The access list is provided by a crypto policy that allows statements to indicate that the selected traffic should be encrypted, and the denial of statements can be used to indicate that the selected traffic should be sent anonymously. With the Cisco Secure VPN Client, you use the windows menu to select a connection that will be protected by IPSec. When exciting traffic is generated or bypassing an IPSec client, the client begins the next step in the process, negotiating the first phase of IKE. Step 1 is displayed

Step 2: The first phase of IKE The primary purpose of IKE's first phase is to secure IPSec peers and establish a secure peer-to-peer channel to enable IKE transactions. The first phase of IKE performs the following functions: • Ensures and protects the identity of IPSec peers • Negotiates a similar IKE SA policy among peers to protect IKE trade

• Create a guaranteed Diffie-Hellman exchange with the result of having matched private keys. • Establishes a secure corridor to negotiate the boundaries of the second phase of IKE

The first phase of IKE occurs in two ways: • Main mode • Aggressive mode

Main Mode The main mode has two dual swaps between the starter and the receiver. • Initial exchange — Algorithms and hashs used to protect IKE connections are agreed upon in comparing IKE SAs for each peer. • Second Transaction — This exchange uses the Diffie-Hellman exchange to generate shared private keys used to generate shared private keys and transfer captions, which are random numbers sent to another party, signed, and returned to prove their ownership. • Third exchange — This exchange guarantees the ownership of the other party. Identity number is the IPSec peer-to-peer Internet address in encrypted form. The main effect of the main mode is to match IKE SAs between peers in order to provide a secure pipeline for the next ISAKMP trade transaction between IKE peers. IKE SA specifies IKE exchange rates: authentication method, encryption and hash algorithms, Diffie-Hellman team used, IKE SA duration in seconds or kilobytes, and private key values shared encryption algorithms . IKE SA for each of its peers is guided twice.

Aggressive Mode In aggressive mode, a few turns are made and there are fewer packets. In the first exchange, almost everything focuses on IKE SA's proposed prices, with the Diffie-Hellman public key, an account signed by another party, and an identity pack, which can be used to verify the identity of the initiator by someone else.

The recipient returns everything needed to complete the exchange. All that is left is for the initiator to confirm the exchange. Weakness to use aggressive mode for both parties to exchange information before there is a secure channel. Therefore, it is possible to smell the phone and find out who is building the new SA. However, aggressive mode is faster than main mode. Step 2 IKE The first phase

Step 3: The second phase of IKE The purpose of the second phase of IKE is to negotiate with IPSec SAs to establish an IPSec tunnel. The second phase of IKE performs the following functions: • Negotiates IPSec SA-protected IKE SA protected parameters • Establishes IPSec security organizations • It also negotiates with IPSec SAs to ensure security • Voluntarily perform additional Diffie-Hellman exchanges Phase 2 IKE has one mode, called quick mode. Quick mode occurs after IKE established a secure tunnel in the first phase. Discusses IPSec shared policy, obtains shared private keys used for IPSec protection algorithms, and establishes IPSec SAs. Quick mode swaps nonce which provides playback security as well. Nonces are used to produce new shared secret items and prevent replay attacks from producing fake SAs. Quick mode is also used to reconfigure the new IPSec SA when the life span of IPSec SA expires. Basic quick mode is used for key upgrades used to create a shared private key based on the key features found in the Diffie-Hellman exchange in the first phase.

Perfect Forward Secrets When perfect forward secrecy (PFS) is defined in IPSec policy, a new DiffieHellman exchange is made in each fast mode, providing significant value with great entropy (life of essentials) and thus greater resistance to cryptographic

attacks. Each Diffie-Hellman exchange requires significant exposure, thereby increasing CPU usage and costing operating costs.

Step 4: IPSec Encrypted Tunnel After the second phase of IKE is completed and the fast mode has established IPSec SAs, the information is exchanged via the IPSec tunnel. Packages are encrypted and extracted using encryption specified in IPSec SA. This encrypted IPSec tunnel can be seen in it

Step 5: Cut the tunnel IPSec SAs is terminated by termination or closure. SA may expire if a certain number of seconds have passed or if a certain number of bytes has passed through the tunnel. When the SAs run out, the keys are discarded. If the next IPSec SA is required to flow, IKE conducts a new second phase and, if necessary, first phase negotiations. Successful negotiations result in new SAs and new keys. New SAs can be established before existing SA expires so that a certain flow can continue without interruption....