Internet Protocol Security
Internet Protocol Security |
|
Before secured data can be exchanged, a contract between the two computers must be established. In this contract, called a security association (SA), both agree on how to exchange and protect information, as shown in Figure 8.6.
Figure 8.6 Internet Key Exchange
To build this contract between the two computers, the IETF has established a standard method of security association and key exchange resolution, called Internet Key Exchange which:
This process protects not only computer to computer communications, but also protects remote computers that are requesting secure access to a corporate network; or any situation in which the negotiation for the final destination computer (endpoint) is actually performed by a security router or other proxy server.
A security association (SA) is a combination of a mutually agreed-upon key, security protocol, and SPI which together define the security that will be used to protect the communication from sender to receiver. The security parameters index (SPI) is a unique, identifying value in the SA used to distinguish among multiple security associations existing at the receiving computer. For example, multiple associations might exist if a computer is securely communicating with multiple computers simultaneously. This situation occurs mostly when the computer is a file server or a remote access server that serves multiple clients. In these situations, the receiving computer uses the SPI to determine which SA is used to process the incoming packets.
To ensure successful, secure communication, IKE performs a two-phase operation. Confidentiality and authentication during each phase is ensured by the use of encryption and authentication algorithms agreed on by the two computers during security negotiations. With the duties split between two phases, keying can be accomplished with great speed.
During the first phase, the two computers establish a secure, authenticated channel—the Phase I SA. It is so named in order to differentiate between the SAs established in each of the two phases. IKE automatically provides the necessary identity protection during this exchange. This ensures no identity information is sent without encryption between the communicating computers, thus enabling total privacy.
Following are the steps in a Phase I negotiation.
The following four mandatory parameters are negotiated as part of the Phase I SA:
If certificates or pre-shared keys are used for authentication, the computer identity is protected. However, if Kerberos v5 authentication is used, the computer identity is unencrypted until encryption of the entire identity payload takes place during authentication.
At no time are actual keys exchanged; only the base information needed by DH to generate the shared, secret key is exchanged. After this exchange, the IKE service on each computer generates the master key used to protect the final round: authentication.
The computers attempt to authenticate the DH exchange. Without successful authentication, communication cannot proceed. The master key is used, in conjunction with the negotiation algorithms and methods, to authenticate identities. The entire identity payload—including the identity type, port, and protocol—is hashed and encrypted using the keys generated from the DH exchange in the second round. The identity payload, regardless of which authentication method is used, is protected from both modification and interpretation.
The sender presents an offer for a potential security association to the receiver. The responder cannot modify the offer. Should the offer be modified, the initiator rejects the responder's message. The responder sends either a reply accepting the offer or a reply with alternatives.
Messages during this phase have an automatic retry cycle which repeats five times. After a brief interval, fall back to clear is established (if IPSec policy allows). Should a response be received before the cycle times out, standard SA negotiation begins.
There is no limit to the number of exchanges that can take place. At a given time, the number of SAs formed are only limited by system resources.
In this phase, SAs are negotiated on behalf of the IPSec service.
The following are the steps in Phase II negotiation.
The IPSec computers exchange their requirements for securing the data transfer:
A common agreement is reached, and two SAs are established: one for inbound and one for outbound communication.
IKE refreshes the keying material and new, shared, or secret keys are generated for authentication, and encryption (if negotiated), of the packets. If a re-key is required, a second DH exchange (as described in "Phase I Negotiation") takes place prior to this, or a refresh of the original DH is used for the re-key.
During this second negotiation of shared policy and keying material—this time to protect the data transfer—the information is protected by the Phase I SA.
As the first phase provided identity protection, the second phase provides protection by refreshing the keying material to prevent bogus SAs. IKE can accommodate a key exchange payload for an additional DH exchange, should a re-key be necessary (master key PFS is enabled). Otherwise, IKE refreshes the keying material from the DH exchange in the first phase.
Phase II results in a pair of security associations: one SA for inbound communication and one SA for outbound; each with its own SPI and key.
The retry algorithm for a message here is almost identical to the process discussed in "Phase I Negotiation," with only one difference: If this process reaches a time-out for any reason during the second or greater negotiation off the same Phase I SA, a re-negotiation of the Phase I SA is attempted. If a message for this phase is ever received with no Phase I SA established, it is rejected.
Using a single Phase I SA for multiple Phase II SA negotiations makes the process extremely fast. As long as the Phase I SA does not expire, re-negotiation and re-authentication are not necessary. The number of Phase II SA negotiations that can be performed is determined by IPSec policy attributes. Note that excessive re-keying off the same Phase I SA could compromise the shared, secret key.
The Phase I SA is cached to allow multiple Phase II SA negotiations (unless PFS is enabled for the master key, or the session key policy lifetimes have been reached). When a key lifetime is reached for the master or session key, the SA is renegotiated, in addition to the key refresh or regeneration.
When the default time-out period is reached for the Phase I SA, or the master or session key lifetime is reached, a delete message is sent to the responder. The IKE delete message tells the responder to expire the Phase I SA. This prevents bogus Phase II SAs from being formed because Phase II SAs are valid until their lifetime is expired by the IPSec driver, independently of the Phase I SA lifetime. IKE does not expire the Phase II SA, because only the IPSec driver knows the number of seconds or bytes that have passed to reach the key lifetime.
Use caution when setting very disparate key lifetimes, which also determine the lifetime of the SA. For example, setting a master key lifetime of eight hours and a session key lifetime of two hours can mean that you have an Phase II SA in place for almost two hours after the Phase I SA expired. This can occur if the Phase II SA is generated immediately before the Phase I SA expires.
