IKE
ISAKMP doesn't define a key exchange. That is left to other protocols. For IPSec the defined key exchange is IKE the Internet Key Exchange. IKE uses the language of ISAKMP to define a key exchange and a way to negotiate security services. IKE actually defines a number of exchanges and options that can be applied to the exchanges. The end result of an IKE exchange is an authenticated key and agreed-upon security services in other words, an IPSec security association. But IKE is not only for IPSec. It is generic enough to negotiate security services for any other protocol that requires them, for instance routing protocols which require authenticated keys like RIP or OSPF.
IKE is a two-phase exchange. The first phase establishes the IKE security association and the second uses that security association to negotiate security associations for IPSec. Unlike ISAKMP, IKE defines the attributes of its security association. It doesn't define the attributes of any other security association, though. That is left up to a domain of interpretation (DOI). For IPSec there exists the Internet IP Security domain of interpretation. Other protocols are free to write their own DOI for IKE.
A DOI defines the optional and required attributes that IKE will negotiate in a phase two exchange. IKE doesn't define its own DOI per se, but it does define the terms and conditions surrounding the use of its security association.
IKE defines two phase one exchanges, one phase two exchange, and two extra exchanges for proper maintenance of its security association. For the phase one exchanges IKE uses the identity protect exchange, and aggressive exchange from the base ISAKMP document and calls them main mode and aggressive mode, respectively. But unlike the ISAKMP exchanges, IKE has fully defined the exchange the contents of all payloads and the steps taken to process them. For phase two, IKE defines a Quick Mode exchange. This negotiates security services for protocols other than IKE primarily IPSec, but, again, IKE is generic enough for a Quick Mode exchange to establish the necessary security services for RIPv2 or OSPF or any other protocol requiring security. The two other exchanges IKE defines are an informational exchange in which IKE peers can communicate error and status information to each other, and a new group exchange that allows IKE peers to negotiate the use of a new Diffie-Hellman group among themselves.
IKE Exchanges
The two phase one exchanges main mode and aggressive mode each accomplish the same thing: establishment of a secure and authenticated communications channel (the IKE SA) and authenticated keys used to provide confidentiality, message integrity, and message source authentication to the IKE communications between the two peers. All the other exchanges defined in IKE have an authenticated IKE SA as a prerequisite. Therefore a phase one exchange, either main mode or aggressive mode, must be performed before any other exchange.
The IKE SA has various parameters that define how it was created and authenticated and how it is to protect phase 2 exchanges. For all these negotiated parameters, IKE defines attributes and the range of values that these attributes may have.
The parameters encryption algorithm, hash algorithm, authentication method, and Diffie-Hellman group are referred to as a protection suite. Protection suites are negotiated as a unit by exchanging ISAKMP SA payloads. Each of the attributes of the protection suite are contained in transform payloads. In addition to those mandatory attributes there are also optional attributes that may be negotiated as part of a protection suite. Foremost among these optional attributes is a lifetime. The lifetime attribute determines how long the IKE SA exists. The longer an IKE SA exists, the greater the risk of leakage of its key, so an implementation is encouraged to include lifetimes in the protection suites offered to peers.
A hash algorithm is negotiated as part of a protection suite, but its use is usually in HMAC form. IKE uses an HMAC version of the hash algorithm as a pseudo-random function (PRF) to generate a seemingly random bitstream. It is possible to negotiate other PRF functions with IKE, but usually an HMAC version of the negotiated hash algorithm is used.
The encryption algorithm and hash algorithm attributes are straightforward. They determine which algorithm will be used for message encryption and authentication. But what about the rest?
The Diffie-Hellman group is a basic attribute that determines the parameters to use when the peers engage in a Diffie-Hellman exchange. You're probably wondering how a single basic attribute can express the required parameters to perform a Diffie-Hellman exchange. This is because IKE defines five groups and assigns unique values to them. Therefore, when a peer refers to "group number 2" the other peer knows the generator and prime modulus of the group implicitly and the two can participate in a Diffie-Hellman exchange. There are three types of Diffie-Hellman groups that can be expressed in IKE traditional exponentiation over a prime modulus (MODP), and two types of elliptic curves, one over G[P] (ECP) and another over G[2N] (EC2N). The groups IKE defines are:
an MODP group with a 768-bit modulus
an MODP group with a 1024-bit modulus
an EC2N group with a 155-bit field size
an EC2N group with a 185-bit field size
a MODP group with a 1680-bit modulus
More groups can be easily defined and using the New Group Exchange two peers can define their own. Only group two is mandatory to implement. It is generally felt that groups 1 and 3 provide roughly similar amounts of security to an exchange, one using a prime modulus and the other an elliptic curve. Similarly, groups 2 and 4 also provide roughly similar amounts of security. The difference between the two is the speed considerations that can be realized by using elliptic curve cryptography (groups 3 and 4) over traditional exponentiation in a finite field (groups 1 and 2). Currently there is no Elliptic Curve analog to group 5.
The attribute with the most impact on the IKE exchange is the authentication method. The other attributes will determine the contents of payloads and how messages are protected, but the authentication method determines which payloads are exchanged and when they are exchanged. An IKE exchange may actually change depending on the authentication method negotiated by the two peers! The acceptable methods of authentication are: (1) preshared keys; (2) digital signatures using the Digital Signature Algorithm; (3) digital signatures using the Rivest-Shamir-Adelman algorithm; and (4) two similar methods of authenticating via exchange of encrypted nonces.
These attributes are negotiated between the peers as part of the first messages they exchange. These are the external and visible characteristics of the IKE SA their negotiation takes place "in the clear". But each side also maintains some secret information that will not be visible to a casual observer (or an active attacker!) of an IKE exchange. This secret information is the keys that are authenticated used to protect IKE messages and also derive keys for other security services. The peers generate a secret, SKEYID, and then three other secrets based on SKEYID: SKEYID_d, which is used to derive keying material for IPSec (and others) SAs, SKEYID_a, which is used to provide data integrity and data source authentication to IKE messages; and, SKEYID_e which is used to encrypt IKE messages. The generation of SKEYID is dependent on the authentication method negotiated. All other SKEYID-based secrets are generated identically, regardless of authentication method.
Each side contributes a cookie and a nonce to SKEYID state generation: The initiator contributes his cookie, CKY-I, and his nonce, Ni; similarly, the responder contributes CKY-R and Nr. These are used as a "liveliness" proof: Each side demonstrates to the other that it possesses the other's nonce and cookie and is therefore "live" and not "Memorex." They also provide some additional freshness to each secret. As a result of the Diffie-Hellman exchange the peers share the Diffie-Hellman shared secret, gxy, which is also used in SKEYID generation. Using '|' to denote concatenation, SKEYID state is generated as follows:
For preshared key authentication:
SKEYID=PRF(preshared-key, Ni | Nr )
For signature authentication:
SKEYID=PRF(Ni | Nr, gxy )
For encrypted nonce authentication:
SKEYID=PRF(hash(Ni | Nr), CKY-I | CKY-R)
where PRF, the aforementioned pseudo-random function, usually the HMAC-version of the negotiated hash function. Once SKEYID has been generated the remainder of the secrets can be generated:
SKEYID_d = PRF(SKEYID, gxy | CKY-I | CKY-R | 0 )
SKEYID_a = PRF(SKEYID, SKEYID_d | gxy | CKY-I | CKY-R | 1 )
SKEYID_e = PRF(SKEYID, SKEYID_a | gxy | CKY-I | CKY-R | 2 )
Note that all SKEYID state is generated by PRF functions. The block size of the PRF function will therefore determine the resulting size of the SKEYID state. For cases where the output of the PRF is too small to be used as an encryption key, SKEYID_e must be expanded. For example, a PRF of HMAC-MD5 will produce 128-bits of output but the Blowfish cipher can require 448 bits of keying material. In this case, SKEYID_e is expanded by using a feedback and concatenation technique until the requisite number of bits has been achieved. Using our MD5 and Blowfish example, SKEYID_e would be the first (high-order) 448 bits of K, where:
K = K1 | K2 | K3 | K4
K1 = PRF(SKEYID, 0)
K2 = PRF(SKEYID, K1, 1)
K3 = PRF(SKEYID, K1, 2)
K4 = PRF(SKEYID, K2, 3)
Phase one exchanges are authenticated by each side computing a hash that only they could know. Since it is impossible to determine the inputs to a hash function from the output of the hash function, and the same inputs will always produce the same output, the production of the appropriate digest authenticates the peer. The computation of the hash is identical regardless of the authentication method negotiated, but the initiator and responder compute their respective digests differently. The initiator's authenticating hash is:
HASH-I = PRF(SKEYID, gi | gr | CKY-I | CKY-R | SA-offer | ID-I )
The responder's authenticating hash is:
HASH-R = PRF(SKEYID, gr | gi | CKY-R | CKY-I | SA-offer | ID-R )
Where gi and gr are the Diffie-Hellman public numbers of the initiator and responder, respectively, SA-offer is the entire SA payload with all protection suites offered by the initiator to the responder, and ID-I and ID-R are the identities of the initiator and responder respectively.
Inclusion of the entire SA payload is important to prevent a man-in-the-middle attack where an attacker could modify the protections suites offered down to their lowest or weakest protection suite. For instance, if both peers would prefer to use Triple-DES as the encryption algorithm but would reluctantly settle for DES, an attacker could modify a request of "Triple-DES or DES" to merely "DES." The responder would reluctantly accept it and neither party would be aware that they could have been communicating more securely. By including the entire offered SA payload in the authenticating hash, such an attack is prevented.
The IKE SA differs from an IPSec SA in that it is bidirectional. There are specific roles assumed by the participants of an exchange. Specifically, one party is the initiator and the other is the responder, but once the SA has been established it may be used to protect both inbound and outbound traffic. Also, regardless of who initiated the phase one exchange that established the IKE SA, either party may initiate a phase two exchange and protect it with the IKE SA. The cookies in the ISAKMP header are not swapped if the responder in phase one becomes the initiator in phase two since the cookie pair is used to identify the appropriate SA in the IKE SADB.
In the following exchange diagrams, payloads encrypted using SKEYID_e as the key are italicized. All ciphers used in IKE must be in CBC mode and therefore require, in addition to a key, an initialization vector (IV). The initial IV is generated by hashing the two Diffie-Hellman public values together, and after each successive encryption and decryption the IV becomes the last ciphertext block processed. In this way the IV chains cipher operations together and "runs" from block to block.
Main Mode Exchange
Main mode uses six messages, in three round trips, to establish the IKE SA. These three steps are SA negotiation, a Diffie-Hellman exchange and an exchange of nonces, and the authentication of the peer. The features of main mode are identity protection and the full use of the ISAKMP's negotiation capabilities. Identity protection is important when the peers wish to hide their identities. The breadth of negotiation capabilities will become apparent when we discuss aggressive mode. As mentioned, the authentication method can influence the composition of payloads and even their placement in messages, but the intent and purpose of the messages the steps taken in Main Mode remain regardless.
When used with preshared key authentication, main mode is the exchange of messages shown in Figure 7.6.
Figure 7.6.
In the first exchange of messages the peers negotiate the parameters of the IKE SA and agree on what the rest of the exchange will look like. They also exchange cookies in the ISAKMP header of each message the initiator chooses his in his first message, placing it in the initiator cookie portion of the ISAKMP header, the responder chooses his in the second message, placing it in the responder cookie portion of the ISAKMP header. In the second exchange of messages the peers exchange Diffie-Hellman public values (computed in the group negotiated as part of a protection suite in the first message exchange) and pseudo-random nonces. At this point the peers can complete their Diffie-Hellman exchange and generate the SKEYID secrets. In the last message exchange the peers identify themselves and exchange the authenticating hash digest. The final two messages exchanged are encrypted with SKEYID_e.
An observant reader will notice that since SKEYID_e must be used before the ID payloads are exchanged, a preshared key can be based only on the IP address of the peer. This is an acknowledged limitation of preshared keys with Main Mode. For most situations this is not an issue, but for remote-access environments where the initiator of the protocol is coming from an IP address that cannot be known a priori there is a problem. The responder cannot maintain preshared keys for addresses that it does not know. An easy way out of this problem is for remote-access environments to use a public key signature-based authentication method and not use preshared keys. If preshared keys must be used, aggressive mode can be used as a phase one exchange since it does not have this limitation. More on aggressive mode later.
Main mode can also be authenticated with public key signatures, either DSS or RSA. Public keys are usually obtained from certificates and IKE allows for certificates to be exchanged and also for certificates to be requested from a peer. Using public key signatures, main mode is the exchange of messages shown in Figure 7.7.
Figure 7.7.
where optional payloads are bracketed. Notice the similarity to main mode with preshared keys. Excluding the optional payloads, the one difference is that the authentication is accomplished by a digital signature and not a hash digest. The optional payloads allow for certificates to be requested the Cert_Req payload and be exchanged the Cert payload.
There are two types of authentication methods that use an exchange of encrypted nonces a standard public key encryption method, and a revised method of public key encryption. The revised method arose because of a criticism against the standard method, that it requires two separate, and expensive, public key encryptions. The revised mode only requires a single public key encryption and encrypts the other payloads with a symmetric cipher. During development of the IPSec and IKE standards there was discussion of removing the standard mode, but since several implementations of it were already in existence another method was added.
Both of these methods have the feature of being repudiable. That is, each side could deny that they were a party to the exchange even if all the messages and state associated with the IKE session are saved. If you've ever done something you don't want anyone to know about, these are the exchanges you should've used to establish your IPSec SAs! The proof of authentication is ability of the peer to decrypt the key and reconstruct the authenticating digest is proof that the peer holds the corresponding private key after all, he was able to decrypt the nonce and therefore is proof of identity. The reason these are deniable is because the nonces exchanged in main mode are encrypted in the peer's public key the initiator's nonce is encrypted with the responder's public key and vice versa. Since anyone can encrypt anything in your public key and since both sides know the entire contents of each side of the exchange, the entire exchange can be faked! Of course, when two parties are actively engaged in one of these exchanges, they have proof of identity via the ability of the peer to compute the right digest, but either party could deny the exchange to a third party at a later date.
Since both these methods use public key encryption it is not possible to use DSS with them. The most common manner of implementing these methods is to use RSA public keys that provide for a way to encrypt with a public key. The El-Gamal variant of the Diffie-Hellman public key cryptosystem is also a viable possibility for use with these methods.
The standard method of public key encryption is the exchange of messages shown in Figure 7.8.
Figure 7.8.
where {}pub_x is used to denote encryption with the public key of "x." Notice that in this exchange the ID payloads are exchanged with the second message. This is because the initiator has to give the responder some indication of his identity so the responder can properly locate his public key and encrypt the response to him. The ID protection feature of main mode is ensured by each peer also encrypting his identity with the public key of the peer.
Two public key encryptions are a drawback of this method. Another is that it does not allow for certificates to be requested or exchanged. To exchange a certificate would be to lose the identity protection of main mode. The initiator must know the identity of the responder prior to initiation of this exchange. This is generally not an issue since the initiator knows where he wants to go on the network and knows to whom he must talk to get there. Since there is no way to pass a certificate in this authentication method each side must support some other method of obtaining certificates.
You're probably asking, why not just encrypt the two payloads together? If both payloads were encrypted together the header of the nonce payload would be hidden. To properly parse the message then, the payload length of the ID payload would have to include the encrypted nonce payload. Such behavior would have a detrimental impact on the receiver of such a packet. A sanity check on the received message would be precluded since there would be no way to check the nonce payload's generic header for correctness. Also, the true length of the ID payload could not be determined. The receiver would have to guess where the ID stops and the generic header of the nonce begins! So, two public key encryptions are required.
As mentioned, the revised method of public key encryption does not have the drawbacks of the standard method. It requires half the public key operations and also provides for a capability for the initiator to provide a certificate to the responder. The initiator must still use some means outside of IKE to obtain the certificate of the responder, though. The revised method of authentication with public key encryption is the exchange of messages shown in Figure 7.9.
Figure 7.9.
where {}ke_x indicates symmetric key encryption with the key "Ne_x." Now you're probably asking: Where does the key for the symmetric cipher come from and which algorithm do you use? Well, the algorithm is the same as that used fo rthe IKE SA, the one negotiated in the exchange of SA payloads. The keys are generated as follows:
Ne_i = PRF(Ni, CKY-I)
Ne_r = PRF(Nr, CKY-R)
So, upon decryption of the nonce, it is possible to compute the appropriate symmetric key and decrypt the remainder of the payloads.
Aggressive Mode Exchange
The purpose of an aggressive mode exchange is the same as a main mode exchange the establishment of an authenticated security association, and keys, which IKE can then use to establish security associations for other security protocols. The major difference is that aggressive mode takes half the number of messages as main mode. By limiting the number of messages, aggressive mode also limits its negotiating power and also does not provide identity protection.
In an aggressive mode exchange, the initiator offers a list of protection suites, his Diffie-Hellman public value, his nonce, and his identity, all in the first message. The responder replies with a selected protection suite, his Diffie-Hellman public value, his nonce, his identity, and an authentication payload for preshared key and encrypted nonce authentication this would be a hash payload, for signature-based authentication it would be a signature payload. The initiator sends his authentication payload as the final message.
The rich negotiation capabilities of IKE are constrained in aggressive mode. This is because the initiator must provide his Diffie-Hellman public value and his nonce in the first message. Obviously, he cannot therefore offer different Diffie-Hellman groups in different protection suites. Also, if he desires to offer authentication based on encrypted nonces this must be his only offer, since the nonce must be encrypted for such an exchange. In addition, if he wishes to do authentication using the revised method of encrypted nonces he cannot offer multiple protection suites with differing encryption or hash algorithm options.
Aggressive mode is decidedly limited! So what use is it then? For remote access situations where the address of the initiator cannot be known by the responder a priori, and both parties desire to use preshared key authentication, this is the only exchange possible to establish the IKE SA. Also, for situations where the initiator knows the policy of the responder, or has a very good idea what that policy is, they may use this exchange to create the IKE SA more quickly. If an employee wishes to remotely access the corporate resources of his company he will most likely know the policies under which access is granted for example, encryption with AES, hashing with SHA, authentication with RSA signatures using certificates signed by the corporate Certification Authority and, therefore, the full power of IKE negotiation is not necessary.
Quick Mode Exchange
Once an IKE SA is established, via a Main Mode or Aggressive Mode exchange, it can be used to generate SAs for other security protocols such as IPSec. These SAs are established via a Quick Mode exchange. A Quick Mode exchange is done under the protection of a previously established IKE SA. Many Quick Modes can be done with a single Main Mode or Aggressive Mode exchange. In fact, simultaneous Quick Modes can be performed under the protection of a single IKE SA!
In a Quick Mode exchange the two peers negotiate the characteristics of, and generate keys for, an IPSec security association. The IKE SA protects a Quick Mode exchange by encrypting it and authenticating the messages. The messages are authenticated via the PRF function, most likely the HMAC version of the negotiated hash function. The SKEYID_a value from the IKE SA state is used as a key to authenticate the entire message of a Quick Mode exchange. This authentication provides data integrity protection as well as data source authentication: Upon receipt we'll know that the message could only have come from our authenticated peer and that the message did not change in transit. Encryption, using SKEYID_e, provides confidentiality to the exchange.
Since multiple Quick Mode exchanges can be performed simultaneously there must be some way to multiplex the IKE messages and determine which message refers to which exchange. The message ID of the ISAKMP header is used for this purpose. Each Quick Mode exchange has a unique message ID which is used with the cookies in the ISAKMP header, to identify the state to which a particular message refers. Also, since all the Quick Mode messages are protected by the same IKE SA, there must be some way to coordinate the initialization vector (IV) for encryption and decryption to prevent two IKE peers from getting out of sync and not being able to decrypt messages the other party encrypted. The message ID is used for this purpose too. Each Quick Mode exchange begins with a unique IV that is derived from the IV from the finished phase one exchange and the message ID of the phase two exchange. The IV for a particular Quick Mode is a running IV similar to that from the phase one exchanges. The initial IV is derived from a deterministic algorithm and subsequent IVs are defined to be the last ciphertext block from the last message. When a Quick Mode exchange is finished, and IPSec SAs have been created, the state the running IV, the nonces, the Diffie-Hellman values that was created to handle this exchange can be deleted. Obviously the state created for the IKE SA is not deleted because it is used to protect subsequent Quick Mode messages.
Quick Mode derives the keys used for the IPSec SAs from its SKEYID_d state. That key is used in the pseudo-random function (same one from phase one) with the nonces passed in the exchange and the protocol and SPI from the IPSec SA offers. This guarantees unique keys for each SA: the inbound SA will have a different SPI and therefore a different key than the outbound SA. All IPSec keys are derived from the same source and are therefore all related. If an attacker was able to determine SKEYID_d from the IKE SA he would have an easy time determining all the keys of all the IPSec SAs derived from that SKEYID_d, and all the keys that are derived in the future too! This is a problem. None of the keys have what is referred to as "perfect forward secrecy," or PFS. Quick Mode has a PFS option to satisfy these concerns.
To provide PFS to a Quick Mode exchange an additional Diffie-Hellman exchange is performed and the resulting shared secret is used in generation of keys for IPSec. Obviously that secret is not retained once the exchange is finished. The memory in which it resides must be zeroed and freed immediately upon completion. Negotiation of the Diffie-Hellman group is not possible in a Quick Mode exchange for the same reason as in an aggressive mode exchange. The initiator must offer his Diffie-Hellman public value derived from the group he is offering. If he offered multiple groups, the responder would have a difficult time correlating public values to SA offers.
In addition to the SA offer(s), the nonce, and the optional Diffie-Hellman public value (if PFS is desired), identity information can also be exchanged by both parties. Both parties have already determined and authenticated each other's identity as part of the phase one exchange, so what are these additional identities for? They're used to exchange selector information that describes the purposes of the SA payloads being established. The IPSec DOI defines identity types and port and protocol fields of the ISAKMP ID payload. Since the DOI deals with phase two exchanges, and, specifically, how to establish SAs for IPSec, these definitions come into effect.
These identities can be a simple address, a range of addresses, or a subnet. Recall in our discussion of IPSec that valid policy could be "all telnet traffic to network 132.239.4.0/255.255.255.0" or "all Web traffic to 132.239.4.24." Using ID payloads in Quick Mode, it is possible to express this policy to the IKE peer. Selector information, in the form of ID payloads, is sent by the initiator of the Quick Mode along with SA offers to the responder. This selector information refers to all SAs negotiated in the single Quick Mode exchange. The responder can use this information to check his own policy and decide whether the initiator is allowed to establish SAs for this purpose. If this policy check passes, the selector information derived from the ID payloads must be provided to the IPSec SADB along with the specifics of the SA. This information constrains the IPSec SA. The SA can only be used for traffic identified by the ID payloads. If the phase 2 identities indicated that negotiation was for telnet to a particular host, the resulting SAs could not be used for any other traffic. Passing the selector information, derived from the phase 2 identities, to the SADB allows the IPSec processing to determine whether the traffic protected by the particular IPSec SA is allowed. Recall the discussion of AH input processing and ESP input processing.
We've described Quick Mode as a simple request/response exchange, but there is more to it than that. The initiator needs a liveness proof that the responder is on-line and has actually processed his initial Quick Mode message. To accomplish this the responder includes the initiator's nonce and the message ID of the exchange in the authenticating hash payload. This digest now not only provides message integrity and source authentication to the initiator, it also provides a liveness proof.
The responder also needs a liveness proof. The message from the initiator could have been an old message replayed by an adversary. The adversary might not have known the contents of the message but he would know through traffic analysis that it was a Quick Mode message. Replaying that message would result in the unnecessary creation of SAs by the responder. This would be considered a denial of service attack, albeit a mild one, because of the memory and SA management overhead that the responder would unnecessarily expend on this message. To prevent such an attack a third message is added to the Quick Mode exchange. In it the initiator includes both nonces and the exchange's message ID in an authenticating hash payload, proving to the responder that he is a real live and active participant in the exchange. At this point the responder may add the SAs to his IPSec SADB as shown in Figure 7.10.
Figure 7.10.
Where:
HASH1 = PRF(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ] )
HASH2 = PRF(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDci | IDcr ] )
HASH3 = PRF(SKEYID_a, 0 | M-ID | Ni | Nr )
Notice how the initiator has all the information necessary to add his IPSec SAs to his SADB before the responder does. After receiving the responder's only message he knows what the responder chose from his offer; if the exchange had PFS he has the responder's Diffie-Hellman public value, and he has a liveness proof. But the responder must wait until he receives the initiator's final message before he's ready. Because of this, the initiator may begin sending IPSec-protected packets prior to the receipt of his final message. In fact, due to network latencies or processor priorities the initiator may choose to give IPSec processing a higher priority to IKE processing the IPSec packets may even arrive at the responder before the final IKE message does! If this happens the responder will drop all the IPSec packets until it is able to process the final IKE message.
Depending on the traffic, this may or may not be a problem. If the traffic is a TCP-based protocol these initial messages would, most likely, be the TCP syn packets and they'll be retransmitted until they're acknowledged. For UDP-based protocols these packets could be irretrievably lost. To prevent this from occurring, IKE uses the commit bit from the ISAKMP header to extend a Quick Mode exchange by one message. Either party can set the commit bit and if one does, the responder must send a final message consisting of an authenticating hash payload followed by a notify payload containing a "connected" message. In this case, the initiator does not add the SAs to his SADB until he receives the "connected" message. This will allow the responder to add his SAs first and be ready when the first IPSec packets begin to flow.
As mentioned earlier, the IKE SA is bidirectional. Either party may initiate a Quick Mode exchange regardless of who initiated the main mode or aggressive mode exchange. When this happens, the roles for phase 2 reverse but the role-specific information from phase 1 does not. The initiator cookie and responder cookie in that order continue to identify the IKE SA used to protect the phase 2 SAs regardless of the role being played in phase 2.
Other IKE Exchanges
All of the exchanges in IKE described so far have been for the creation of SAs the phase one exchanges create the IKE SA and the phase two exchange creates IPSec SAs. IKE defines two other exchanges that provide for maintenance of the IKE SA and for negotiation of private Diffie-Hellman groups.
The IKE informational exchange allows IKE peers to send status and error messages to each other. This is not an exchange per se, but just a single message that is not acknowledged nor, due to the UDP-based nature of IKE, guaranteed to arrive. Because of the unreliability of informational exchange messages, they are not mandatory to send. Implementers are strongly encouraged to be "good citizens" and use them, but they should not design their code to expect them. The most common use of the informational exchange is to tell a peer that a particular SA, either the IKE SA or an IPSec SA, has been deleted and to refrain from using it.
Informational exchanges are similar to Quick Mode messages in that they all have a unique message ID and generate a unique IV to use for encrypting the message. They are also authenticated with a hash payload, which is the result of the keyed PRF function taking SKEYID_a as the key and a concatenation of the message ID and the entire notify or delete payload. Since this is a single, unacknowledged message the state associated with this exchange can be freed after sending the message.
Another exchange IKE defines is a new group exchange. IKE defines five Diffie-Hellman groups that peers can use, three groups using exponentiation over a prime modulus, and two groups using elliptic curves. The new group exchange allows peers to negotiate private groups for their use and define a group identifier that they can subsequently use in a later exchange to identify the group. This exchange must be protected by the IKE SA due to the sensitive nature of the data being exchanged. Therefore, a new group exchange, while not strictly being a phase two exchange, must follow a phase one exchange and must be protected by the IKE SA. Similar to a Quick Mode and informational exchange, the protection takes the form of encryption using SKEYID_e and an authenticating hash function keyed with SKEYID_a.
The new group exchange is a request-response exchange in which the initiator sends an SA payload that contains the characteristics of the group being proposed and an identifier out of the range of numbers reserved for private use. For instance, to propose a new group that uses exponentiation over a prime modulus, the initiator would send the prime number and the generator. If this group is acceptable to the responder it responds with an identical response. It is strongly recommended that the responder test the group for strength and not blindly accept any offer. For instance, in an offer of a group using exponentiation over a prime modulus, the modulus offered should be checked for primality. If it is not prime, the offer should be refused.
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |