| 0 comments ]

IKE Protocol

Add a note hereIPsec implements a VPN solution using an encryption process that involves the periodic changing of encryption keys. IPsec uses the IKE protocol to authenticate a peer computer and to generate encryption keys. IKE negotiates a security association (SA), which is an agreement between two peers engaging in an IPsec exchange, and consists of all the required parameters necessary to establish successful communication.

Add a note hereIPsec uses the IKE protocol to provide these functions:

  • Add a note hereNegotiation of SA characteristics

  • Add a note hereAutomatic key generation

  • Add a note hereAutomatic key refresh

  • Add a note hereManageable manual configuration

Add a note hereTo establish a secure communication channel between two peers, the IKE protocol uses the following three modes of operation:

  • Add a note hereMain mode: In main mode, an IKE session begins with one computer (the initiator) sending a proposal or proposals to another computer (the responder). The proposal sent by the initiator defines what encryption and authentication protocols are acceptable, how long keys should remain active, and whether Perfect Forward Secrecy (PFS) should be enforced. There are three exchanges typical of the main mode:

    • Add a note hereThe first exchange between the initiator and the responder establishes the basic security policy. The responder chooses a proposal best suited to the security situation and then sends that proposal to the initiator.

    • Add a note hereThe next exchange passes DH public keys between the two users. DH key exchange is a cryptographic protocol that allows two parties that have no prior knowledge of each other to establish a shared-secret key over an unsecure communications channel. All further negotiation is encrypted within the IKE SA.

    • Add a note hereThe third exchange authenticates an Internet Security Association and Key Management Protocol (ISAKMP) session. Once the IKE SA is established, IPsec quick mode negotiation begins.

  • Add a note hereAggressive mode: Aggressive mode compresses the IKE SA negotiation phases described thus far into three packets. In aggressive mode, the initiator passes all data that is required for the SA. The responder sends the proposal, key material, and ID and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder IDs pass in plaintext.

  • Add a note hereQuick mode: Quick mode IPsec negotiation takes place after successful IKE SA negotiation. Quick mode is similar to aggressive mode IKE negotiation, except that negotiation is protected within an IKE SA. Quick mode negotiates the SA for the data encryption and manages the key exchange for that IPsec SA.

Add a note hereTo establish a secure communication channel between two peers, the IKE protocol executes the following phases:

  • Add a note hereIKE Phase 1: In IKE Phase 1, two IPsec peers perform the initial negotiation of SAs. In this phase, the SA negotiations are bidirectional; data may be sent and received using the same encryption key. In IKE Phase 1, the transform sets, hash methods, and other parameters are determined. Optionally, IKE Phase 1 can include authentication, in which each peer in the SA negotiation is able to verify the identity of the other. Even if the SA negotiation data stream between the two IPsec peers is compromised, there is little chance that the encryption keys could be guessed and thus the traffic decrypted.

  • Add a note hereIKE Phase 2: In IKE Phase 2, SAs are negotiated by the IKE process ISAKMP on behalf of other services, such as IPsec, that need encryption key material for operation. Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow.


    Note

    Add a note hereOther, optional parameters are sometimes negotiated between IKE Phase 1 and IKE Phase 2, such as level of DH, encryption algorithms, and methods of authentication.

Add a note hereIKE Phase 1

Add a note hereThe basic purpose of IKE Phase 1, shown in Figure 5-15, is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the peers. IKE Phase 1 occurs in two modes: main mode and aggressive mode.

Click to collapseImage from book
Add a note hereFigure 5-15: IKE Phase 1

Add a note hereMain mode has three two-way exchanges between the initiator and receiver:

  • Add a note hereFirst exchange: Peers negotiate and agree on the algorithms and hashes that will be used to secure the IKE communications.

  • Add a note hereSecond exchange: DH generates public and private values. The peers exchange their public values, and the result is a shared secret. The shared-secret key is used to generate all the other encryption and authentication keys.

  • Add a note hereThird exchange: The identity of the other side is verified. The main outcome of main mode is a secure communications path for subsequent exchanges between the peers.


Note

Add a note hereIn aggressive mode, fewer exchanges are done, and the exchanges have fewer packets. As an example, with aggressive mode, the peers will exchange their identity and a hash of the PSK even though DH have not been negotiated yet, and therefore there is no shared secret to send data in an encrypted format.

Add a note hereIKE Phase 1: Example

Add a note hereWhen you are trying to make a secure connection between Host A and B through the Internet, a secure path (a tunnel) is established between Router A and Router B. Through the tunnel, the encryption, authentication, and other protocols are negotiated.

First Exchange: IKE Policy Is Negotiated

Add a note hereRather than negotiate each protocol individually, the protocols are grouped into sets, called IKE policy sets. IKE policy sets are exchanged during the IKE main mode, first exchange phase. If a policy match is found between peers, main mode continues. If no match is found, the tunnel is torn down.

Add a note hereIn Figure 5-16, Router A sends IKE policy sets 10 and 20 to Router B. Router B compares its set, policy set 15, with those received from Router A. In this instance, there is a policy match. Policy set 10 of Router A matches the policy set 15 of Router B.

Click to collapseImage from book
Add a note hereFigure 5-16: First Exchange: IKE Policy Is Negotiated

Note

Add a note herePolicy set numbers are only locally significant to a VPN device. The policy set numbers do not have to match between two VPN peers.

Add a note hereIn a point-to-point application, each end may need only a single IKE policy set to be defined. However, in a hub-and-spoke environment, the central site may require multiple IKE policy sets to satisfy all the remote peers.

Second Exchange: DH Key Exchange

Add a note hereWhen the IKE policy is agreed on, including the size of the prime number to be used for DH, the two peers run the DH key exchange protocol, as shown in Figure 5-17. The result of DH will be the creation of a shared secret that is needed by the various encryption and hashing algorithms upon which IKE and IPsec will ultimately agree.

Click to collapseImage from book
Add a note hereFigure 5-17: Second Exchange: DH Key Exchange

Add a note hereSeveral levels of DH key exchanges are available in Cisco IOS Software:

  • Add a note hereDH Group 1: A key exchange that uses a 768-bit prime number. This group is the usual choice when the encryption algorithm is DES.

  • Add a note hereDH Group 2: A key exchange that uses a 1024-bit prime number. This group is the usual choice when using 3DES for encryption.

  • Add a note hereDH Group 5: A key exchange that uses a 1536-bit prime number. DH 5 should be used with AES.

  • Add a note hereDH Group 7 (elliptic curve cryptography [ECC]): A key exchange that generates IPsec keys when the elliptic curve field is 163 bits. This group was designed to be used with low-powered hosts such as PDAs.

Third Exchange: Authenticate Peer Identity

Add a note hereWhen you are conducting business over the Internet, it is necessary to know who is at the other end of the tunnel. The device on the other end of the VPN tunnel must be authenticated before the communications path is considered secure. The last exchange of IKE Phase 1 authenticates the remote peer, as illustrated in Figure 5-18.

Click to collapseImage from book
Add a note hereFigure 5-18: Third Exchange: Authenticate Peer Identity

Add a note hereThere are three data origin authentication methods:

  • Add a note herePSKs: PSKs are a secret key value that is entered into each peer manually and is used to authenticate the peer.

  • Add a note hereRSA signatures: RSA signatures are the exchange of digital certificates that is used to authenticate the peers.

  • Add a note hereRSA encrypted nonces: Nonces are random numbers that are generated by each peer and are encrypted and then exchanged between peers. The two nonces are used during the peer-authentication process.

Add a note hereIKE Phase 2

Add a note hereThe purpose of IKE Phase 2 is to negotiate the IPsec security parameters, as shown in Figure 5-19, that will be used to secure the IPsec tunnel. IKE Phase 2 performs the following functions:

Click to collapseImage from book
Add a note hereFigure 5-19: IKE Phase 2
  • Add a note hereNegotiates IPsec security parameters, known as IPsec transform sets

  • Add a note hereEstablishes IPsec SAs

  • Add a note herePeriodically renegotiates IPsec SAs to ensure security

  • Add a note hereOptionally performs an additional DH exchange

Add a note hereIKE Phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in Phase 1. It negotiates a shared IPsec transform, derives shared-secret keying material that the IPsec security algorithms will use, and establishes IPsec SAs. Quick mode also exchanges nonces that are used to generate new shared-secret key material and prevent replay attacks from generating false SAs.

Add a note hereQuick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires. Basically, quick mode refreshes the keying material that creates the shared-secret key based on the keying material derived from the DH exchange in Phase 1.

Add a note hereEarlier, the text mentioned Perfect Forward Secrecy (PFS). The basic principle of PFS is that new keys (shared secrets) cannot be derived from older keys. The idea is that if keys are compromised, previous and subsequent keys are secured because they were generated from scratch and not derived. Therefore, PFS exists when a DH exchange is done at each rekeying interval, which is preferable, but might not be necessary, instead of deriving the new keys from the previous keys.


Key Topic

Add a note hereIKE negotiates matching IPsec policies.


Note

Add a note hereBecause a picture is worth a thousand words, Figure 5-20 is the visual representation of IPsec I created to teach students the sequence of events when tunnels are being built. The process starts at the bottom of the figure with IKE Phase 1, followed by IKE Phase 2, and finally with the two unidirectional IPsec tunnels coming up to exchange the encrypted data.

Click to collapseImage from book
Add a note hereFigure 5-20: Visual Representation of IPsec Tunnels Being Built

0 comments

Post a Comment