I’ll now discuss Internet Security Association Key Management.
Internet Key Exchange
Internet Key Exchange (IKE) is the facilitator and manager of IPSec−based conversations and is a derivative of Internet Security Association Key Management Protocol/Oakley (ISAKMP/Oakley), specifically for IPSec. IPSec uses the services of IKE to authenticate peers, manage the generation and handling of the keys used by the encryption algorithm, as well as the hashing algorithms between peers. It also negotiates IPSec security associations.
IKE provides three modes for exchanging key information and setting up IKE SAs. The first two modes are Phase 1 exchanges, which are used to set up the initial secure channel; the other mode is the Phase 2 exchange, which negotiates IPSec SAs. The two modes in Phase 1 are main mode and aggressive mode, and the Phase 2 mode is called quick mode. An IKE SA is used to provide a protected pipe for subsequent protected IKE exchanges between the IKE peers and then use Phase 2 quick mode with the IKE SA to negotiate the IPSec SAs.
Main mode has three two−way exchanges between the initiator and receiver. In the first exchange, the algorithms and hashes are agreed upon. The second exchange uses Diffie−Hellman to agree on a shared secret and to pass nonces. (Nonces are random numbers sent to the other party and signed and returned to prove their identity. The third exchange verifies the identity of the other peer.
In aggressive mode, fewer exchanges are done using fewer packets than with main mode. On the first exchange, almost everything is squeezed in—the proposed SA. The receiver sends back everything that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The disadvantage of using the aggressive mode is that both sides have exchanged information before there is a secure channel. Therefore, it is possible to snoop the wire and discover who formed the new SA. However, aggressive mode is faster than main mode.
Quick mode occurs after IKE has established the secure tunnel. Every packet is encrypted using quick mode. Both negotiation of the IPSec SA and derivation of the key material needed by IPSec are accomplished in quick mode. Before IKE will proceed, the potential parties are required to agree upon a way to authenticate themselves to each other. This authentication method is negotiated during the IKE Phase 1 main mode exchange.
Before any traffic can be passed using IPSec, each router/firewall/ host must be able to verify the identity of its peer. This is accomplished by authenticating each peer, and IKE supports multiple authentication methods as part of the Phase 1 exchange. The two entities must agree on a common authentication protocol through a negotiation process. IPSec supports the following negotiation processes:
Public key cryptography (nonces)
When pre−shared keys are used, identical keys are configured on each host. IKE peers authenticate each other by computing and sending a keyed hash of data that includes the pre−shared key. If the receiving peer is able to create the same hash using its pre−shared key, then it knows that both parties share the same secret key, thus authenticating the other party. Pre−shared keys do not scale well because each IPSec peer must be configured with the key of every other peer with which the router needs to establish a session.
When using public key cryptography, each party generates a pseudo−random number (a nonce) and encrypts it in the other party’s public key. The ability for each party to compute a keyed hash containing the other peer’s nonce, decrypted with the local private key as well as other publicly and privately available information, authenticates the parties to each other. This system provides for deniable transactions. That is, either side of the exchange can plausibly deny that it took part in the exchange. Currently, only the RSA public key algorithm is supported.
When digital signatures are used, each device digitally signs a set of data and sends it to the other party. This method is similar to public key cryptography, except that it provides nonrepudiation.
Sharing keys does not scale well for a large network. One method that does scale is encapsulation of the public key in a digital certificate authenticated by a Certificate Authority (CA). A CA is a trusted third party who can bind a public key to an identity. In this case, that includes the identity of devices, especially router and firewall devices.
In summary, when the IKE negotiation begins, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its configured policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the other peer’s received policies. The remote peer checks each of its configured policies in the order of its highest priority first until a match is found.
A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie−Hellman parameter values and when the remote peer’s policy specifies a lifetime less than or equal to the lifetime in the policy being compared. If no acceptable match is found, IKE refuses negotiation and IPSec will not be established. If a match is found, IKE will complete negotiation and IPSec security associations will be created.
Diffie−Hellman Key Agreement
Diffie−Hellman provides a means for two parties to agree upon a shared secret in such a way that the secret will be unavailable to eavesdroppers. Diffie−Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining your private key and the other party’s public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material.
Each peer generates a public key and private key pair. The private key that is generated by each peer is never shared; the public key is calculated from the private key by each peer and the result is exchanged with the other peer. Each peer combines the other peer’s public key with its own private key and each peer computes the same shared secret number. The shared secret number is then converted into a shared secret key, which is used for encrypting data using the encryption algorithm specified during the security association setup.
The Diffie−Hellman key agreement has two system parameters, p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p with the following properties: for every number n between 1 and p‘ inclusive, there is a power k, of g k such that n = gk modulus p. The Diffie−Hellman key agreement can be explained further using the following example:
1.The Diffie−Hellman process begins with each host creating a prime number, p (which is larger than 2) and a base number, g, an integer that is smaller than p.
2.Next, the hosts each secretly generate a private number called x, which is less than p 1.
3.The hosts next generate the public keys, y. They are created with the following function:
y = gx % p
4.The two hosts now exchange the public keys (y) and the exchanged numbers are converted into a secret key, z:
z = yx % p
5.The value z can now be used as the key for the IPSec encryption method used to transfer information between the two hosts. Mathematically, the two hosts should have generated the same value for z.
6.This yields the following:
z = (gx % p)x’ % p = (gx’ % p)x % p
On Cisco devices, Diffie−Hellman can be configured to support one of two different group modes on a per−IKE−policy basis: 768−bit groups or 1024−bit groups. The 1024−bit groups are more challenging to break, but they come with the added expense of being more CPU intensive.