In a nutshell, ISAKMP defines a generic high-level framework with abstract syntax and semantics for automatic keying. The framework defines the parameters and payload formats for negotiating an SA, establishing the SA, modifying the SA and removing the SA at the conclusion of the secure communication.
FIGURE 5-153
FIGURE 6-19
Through the ISAKMP framework, two nodes can agree on the type of security services, also known as a protection suite, to be afforded to the communication about to take place: for example, the security services that use IPsec in tunnel-mode with ESP having 3-DES as the encryption algorithm, and with AH having the HMAC-MD5 as the authentication method.
The two nodes must exchange information to authenticate each other and then generate a set of secret keys to be shared exclusively between them. The generated keys must have the perfect forward secrecy property (i.e., the set of keys generated in one session is independent of the set of keys generated in another session). The establishment and the management of the secret keys are integral parts of the overall management of the security associations to which the secret keys apply.
The protection suite specifies the properties of the secret key such as key size, lifetime, and its refreshment policy. The protection suite also specifies information such as the cryptographic algorithms that will be using the keys, and the parameters of the cryptographic algorithms such as what the initialization vectors are.
In the ISAKMP framework, one node is the initiator of the secure communication and the other node is the responder. The initiator sends the responder a proposal containing a list of protection suites in decreasing order of preference. The responder then selects one of the protection suites from the proposal and indicates its selection back to the initiator. The next step is the generation of the shared key once the two nodes agree on a protection suite. As discussed in Section 6.5.2, the SA is composed of the protection suite, the shared keys, and the identities of the two parties. This process is known as negotiation.
More precisely speaking, an ISAKMP proposal is encoded and carried in both a Proposal payload and one or more Transform payloads. The Proposal payload specifies the security protocol, which can be ISAKMP, IPsec ESP, IPsec AH, etc. The Transform payload lists the exact algorithm of the security protocol. For example, if the Proposal payload specifies the IPsec ESP as the security protocol, then the Transform payload may list 3-DES as the algorithm. Each Transform payload also carries the SA attributes such as the SA lifetime or the key size for the cryptographic algorithm.
ISAKMP Exchanges
The ISAKMP terminology, exchange, refers to an ISAKMP predefined template that specifies the number of messages sent by each party, the types of payloads included in each message, and how to process the payloads of each message.
The ISAKMP framework uses a two-phase negotiation. The Phase-I negotiation establishes an ISAKMP SA, also known as Phase-I SA that protects the Phase-II negotiation. The Phase-II negotiation establishes SAs on behalf of other security protocols to protect data traffic. In the IPsec Domain of Interpretation (DOI) these Phase-II SAs are called IPsec SAs. DOI is discussed in Section 6.9.2. Figure 6-20 illustrates the ISAKMP two-phase negotiation.
All of the Phase-II exchanges carried out for the establishment of the Phase-II SAs are protected under Phase-I SA. Phase-II exchanges can be optimized to reduce both the number of messages exchanged and the amount of information carried in the messages by using the already protected communication path. The key generation algorithms and exchange protocols deployed in Phase-II should be more efficient because there are a large number of SAs established in Phase-II.
FIGURE 6-20
FIGURE 5-155
FIGURE 6-22
The ISAKMP exchanges are: Base Exchange, Identity Protection Exchange, Authentication Only Exchange, Aggressive Exchange, and Informational Exchange.
Figure 6-21 illustrates the Base Exchange. The numeric values in brackets are the message numbers. The Base Exchange has four messages in total. HDR is the message header. Nonce is a large random number. The initiator sends the SA proposal and the responder replies with its choice of the protection suite. KE is the key exchange payload defined by the ISAKMP framework, which is used to generate the shared secret for the SA. IDi contains the identity information of the initiator, and IDr contains the identity information of the responder. The Base Exchange combines the keying information and the authentication information in one message as shown in messages (3) and (4). The agreed authentication function protects both the keying material and the identities of the two parties during the exchange, but the identity information is not encrypted because the shared key has not been established until the initiator processes the message (4).
Figure 6-22 illustrates the ISAKMP Identity Protection Exchange. The identities of the two parties are protected at the expense of two additional messages in the Identity Protection Exchange.
FIGURE 5-156
FIGURE 6-24
The identity information is encrypted because the keying information is exchanged in messages (3) and (4) followed by the exchange of identities in messages (5) and (6). The symbol HDR* means all of the payloads are encrypted. In Figure 6-22, the payloads are the ID and the Auth data.
Figure 6-23 illustrates the ISAKMP Authentication Only Exchange. With the Authentication Only Exchange, the responder replies with its choice of the protection suite. In addition, the responder identity information is transmitted in message (2) under the protection of the agreed authentication function. The initiator transmits its identity information under the protection of the agreed authentication function.
Figure 6-24 illustrates the ISAKMP Aggressive Exchange. The Aggressive Mode Exchange combines the SA proposal, key exchange and identity information into one message. The SA proposal limits the protection suite to a single Proposal payload and a single Transform payload. The responder will reply if it accepts the protection suite. The reply message is protected under the proposed authentication function, which includes the key exchange payload and the identity information of the initiator. As Figure 6-24 shows, the identity information is not encrypted.
The reason that we refer to ISAKMP as a framework instead of as a protocol is because ISAKMP defines high-level payload formats but does not provide sufficient detail necessary for actual implementation. A Domain of Interpretation and a particular key exchange protocol defines a specific context in which ISAKMP operates. This context specifies the necessary and detailed information for implementing ISAKMP in that context.
Domain of Interpretation
A Domain of Interpretation (DOI) defines various situations, with each situation describing the characteristics of a particular type of communication requiring security protection. A situation maps to a set of security services to be provided by both the initiator and the responder in order for the communication to take place. For each situation, the DOI provides the details on the format of the various payload contents, the exchange types, and the conventions for the naming (or the encoding) of security-relevant information. The ISAKMP exchange types are described in Section 6.9.1.
For example, the Internet IP Security Domain of Interpretation for ISAKMP [RFC2407] defines the context in which to interpret the ISAKMP payloads when ISAKMP is used with IP and IP security protocols. The [RFC2407] also defines the attribute types for the Internet Key Exchange Protocol Phase II SA negotiation, and how to encode each attribute type.
Internet Key Exchange Protocol
The Internet Key Exchange (IKE) protocol is a hybrid protocol of the Oakley and Skeme key exchanges, which is designed according to the ISAKMP framework. IKE is a protocol that negotiates and establishes both the ISAKMP SA and the IPsec SAs. IKE manages the SA and re-establishes the SA if its lifetime expires. Such SA lifetime management prevents sequence number wrapping and minimizes the risk of replay attacks. IKE facilitates the easy and secure management of SA entries.
IKE Phase I negotiation establishes an ISAKMP SA through either the Identity Protection exchange or the Aggressive Mode Exchange. In the context of the IKE, the Identity Protection exchange is termed the Main Mode, and the Aggressive Mode exchange is termed the Aggressive Mode. The ISAKMP SA is a bi-directional SA in that each part can initiate the Phase II negotiation. Three shared keys are established between the initiator and the responder at the conclusion of IKE Phase I negotiation. One of the keys is used for authentication. Another key is used for encryption of the fifth and sixth message of the IKE Main mode exchange as shown in Figure 6-22. This key is also used for encryption of all Phase II traffic. The third shared key is used for deriving keys for non-ISAKMP security associations.
IKE Phase II negotiation establishes IPsec SAs through a newly defined exchange termed the Quick Mode. The Quick Mode exchange is more efficient because the exchange assumes protection from the ISAKMP SA. IKE Phase II negotiation establishes two uni-directional SAs, one for inbound traffic and one for outbound traffic.
FIGURE 6-25
IKE can create all necessary SAs automatically. The only requirement for this mechanism to work is that the two end nodes must have a shared secret to create ISAKMP session between them as discussed in Section 6.9.1. The way to install such a secret is outside of the IKE mechanism, for example, install a shared key on both nodes or retrieve the peer’s identifier by using the Public Key Infrastructure (PKI) mechanism.
Figure 6-25 provides a simplified view of the relationships among IP security protocol stack, IP security databases (SAD and SPD) and IKE.
As Figure 6-25 illustrates, as a first step the IPsec module examines the SPD to determine if IPsec processing is enabled on the outgoing traffic. For IPsec processing enabled traffic that does not have a corresponding entry in the SAD, the IPsec module requests the IKE module to establish the necessary SA. The IKE module negotiates and performs the necessary exchange with the peer IKE module to establish the SA. Then the IKE module inserts this new SA into the SAD.
