Tải bản đầy đủ
17 The Phase 2 Negotiation 112

17 The Phase 2 Negotiation 112

Tải bản đầy đủ

The Fourth Puzzle Piece: The Internet Key Exchange (IKE)

113

5.17.1 Quick Mode

A phase 2 Quick Mode exchange has three goals.
• To negotiate security parameters. The initiator and the responder

must agree on the values and settings of a number of parameters that
will govern the operation of the negotiated IPsec SA. They also must
negotiate the maximum lifetime of the SA and how that lifetime
will be measured. If PFS is desired, they also must communicate the
parameters used to generate the shared secret that will be used to
calculate the phase 2 keying material and establish the shared secret
itself.

• To prevent replay. Authenticating hashes, which include freshly gen-

erated nonces, are exchanged and verified to ensure that the negotiation is not merely a replay of a previous phase 2 negotiation.

• To generate keying material. Using the shared secret from phase 1 (or

a newly generated shared secret if PFS is required), the keying material for the IPsec SA is produced. The phase 2 nonces also are used in
the process, to ensure the freshness of the keying material.

In addition, two additional goals may be satisfied.
• To provide PFS of keys and/or identities. PFS is a guarantee that only

one key has been generated from a single Diffie-Hellman exchange
and that the key has no relationship to any other keys used between
the peers. That ensures that discovery of the key by a third party will
jeopardize only traffic protected with the single discovered key but
not traffic protected by another key negotiated by the peers. PFS of
keys is provided by performing a second Diffie-Hellman exchange
during phase 2 and generating the IPsec SA’s key from the new
shared secret rather than using the same shared secret used to generate the phase 1 authentication key (SKEYID_a) and encryption key
(SKEYID_e). PFS of identities is provided by deleting the phase 1
ISAKMP SA after it has been used for a single phase 2 Quick Mode
exchange.

• To exchange identities. If the address of the negotiating peer is not

sufficient to characterize the IPsec SA, the endpoint identities must
be exchanged. This is necessary in the following cases:

114

Demystifying the IPsec Puzzle



The peer is negotiating an SA on behalf of another entity (e.g., a
gateway negotiating a tunnel-mode SA for one or more clients);



Multiple SAs exist between the peers, each of which is characterized by different port and/or protocol numbers, different identities, or other combinations of selectors.

A phase 2 Quick Mode exchange consists of three messages (two messages
from the initiator to the responder and one message from the responder to
the initiator). Figure 5.17 shows the payloads contained in each Quick Mode
message. The first two Quick Mode messages (message 1 from the initiator
to the responder and message 2 from the responder to the initiator) always
contain a hash payload, an SA payload, and a nonce payload. The hash contained in the hash payload serves to authenticate the message; it is a keyed
hash, using SKEYID_a as the key, of the phase 2 message ID and all
the other payloads in the message. The nonce is proof of the liveness of the
exchange, protecting against a replay attack.
A phase 2 message can contain multiple SA payloads, which results in
the negotiation of multiple IPsec SAs. Each SA payload can contain multiple
proposal payloads, each of which characterizes a different protocol to be provided by the SA, and each proposal payload can have multiple, alternative
transform payloads. The responder’s SA payload contains a single proposal
(for each protocol for each proposed SA) that the responder selected from all
the proposals offered by the initiator (for that SA). Figure 5.18 contains a
sample Quick Mode initiator proposal. As a proposal, it allows the responder
too many choices; as an example, it is instructive. The first two rows
allow the responder to select an ESP SA with a choice of algorithms,

HDR, {HASH, SA, NONCE, [KEY],

2

Initiator

HDR, {HASH, SA, NONCE, [KEY],
[ID, ID]}

Figure 5.17 Quick Mode exchange.

3

HDR, {HASH}

Responder

1

[ID, ID]}

The Fourth Puzzle Piece: The Internet Key Exchange (IKE)

Proposal Transform
#
#
Protocol

Enc
Alg

Auth
Alg

Encapsulation
DH
Lifetime
Mode
Group # in Sec

115

Lifetime
in KB

Tunnel

5

1800

—

MD5

Tunnel

1

900

500

—

SHA-1

Tunnel

—

900

500

ESP

Triple DES

—

Tunnel

—

900

500

ESP

DES

—

Tunnel

—

900

500

1

1

ESP

1

2

ESP

DES

2

1

AH

2

1

2

2

Triple DES SHA-1

Figure 5.18 Sample Quick Mode initiator proposal.

Diffie-Hellman groups, and lifetimes. The inclusion of a Diffie-Hellman
group in phase 2 indicates that the initiator wants PFS. The responder can
send back a proposal corresponding to either of these “row” proposals. The
last three rows are somewhat more complicated. Row 3 proposes an AH SA
in conjunction with either the ESP SA in row 4 or the one in row 5. To select
that combination, the responder would have to return a proposal corresponding to row 3 and another proposal corresponding to either row 4 or
row 5. In that case, PFS is not selected. If it were, the Diffie-Hellman groups
all would have to be the same.
If PFS of keys is required, the first two messages also include KEY
payloads, and an additional Diffie-Hellman exchange occurs. If either of the
negotiating peers is a gateway, negotiating an SA for some other host(s) or
client, the messages also include two ID payloads, the first of which includes
the identity of the initiator’s client and the second of which includes the
identity of the responder’s client. Unlike Main Mode, in Quick Mode
the identities are sent together with the proposal payload, so the responder is
able to make an informed choice about which proposal to accept, including
the initiator’s client ID in the decision-making process if necessary.
After the first two messages have been exchanged, each peer possesses
enough information to calculate the keying material that will be used for
the IPsec SAs. Figure 5.19 shows the Quick Mode key calculations with and
without PFS. Figure 5.20 illustrates the iterative expansion method used in
Quick Mode to expand the keying material if the formula in Figure 5.19
does not yield a value of the required length. This keying material might
be used for the authentication key of an AH SA, or it might be divided to
provide the authentication key and the encryption key for an ESP SA.

116

Demystifying the IPsec Puzzle
Keying Material (without PFS) = Keyed HMAC of protocol (AH or ESP), SPI,
Initiator’s Nonce, Responder’s Nonce
with Key = SKEYID_d
Keying Material (with PFS) = Keyed HMAC of
Quick Mode Diffie-Hellman shared secret,
protocol (AH or ESP), SPI, Initiator’s Nonce, Responder’s Nonce
with Key = SKEYID_d

Figure 5.19 Quick Mode key calculations.



Key1 = Keyed HMAC of [Quick Mode Diffie-Hellman shared secret,]
protocol (AH or ESP), SPI, Initiator’s Nonce, Responder’s Nonce
with Key = SKEYID_d
Key2 = Keyed HMAC of Key1, [Quick Mode Diffie-Hellman shared secret,]
protocol (AH or ESP), SPI, Initiator’s Nonce, Responder’s Nonce
with Key = SKEYID_d
Key3 = Keyed HMAC of Key2, [Quick Mode Diffie-Hellman shared secret,]
protocol (AH or ESP), SPI, Initiator’s Nonce, Responder’s Nonce
with Key = SKEYID_d

Expanded Keying Material = Key1, Key2, Key3, …

Figure 5.20 Quick Mode key boost calculations.

The first exchange negotiates the IPsec SA’s policy and parameters
and generates the keying material in an authenticated manner that protects
against a replay of a previous negotiation. The last message, from the initiator
to the responder, concludes the exchange and reassures the responder that
the responder’s proposal was received. It consists of a hash payload, with a
keyed hash computed over the message ID and the nonces from messages
1 and 2.
Once the IPsec SAs have been established, they can be used to protect
all or some of the traffic between the endpoints, until their lifetimes expire or
some other untoward event occurs (such as a rebooting of the machine that
causes the SAs to be lost).
5.17.2 The Commit Bit

The commit bit shifts the onus of verifying and finalizing the IPsec SA’s
establishment from the initiator to the responder. Without the commit bit,

The Fourth Puzzle Piece: The Internet Key Exchange (IKE)

117

Quick Mode is a three-message protocol. After the first two messages have
been exchanged, the peers have all the data necessary to compute the keying
material and establish the IPsec SA. In the third message, the initiator computes an authenticated hash on both the initiator’s Quick Mode nonce
and the responder’s Quick Mode nonce. Including the nonce that was just
received from the responder serves to reassure the responder that this is a
bona fide negotiation and not a replay of a previous one. But what if that
message is lost? The initiator, assuming that it has arrived safely, will establish
the IPsec SA; the responder, not having received the final Quick Mode message, will wait to establish the SA.
Either peer can convert Quick Mode into a four-message protocol by
turning on the commit bit in the ISAKMP header. That way, if the initiator
does not receive the fourth message, it will resend the third message. There is
no ideal solution, because any lost message can create complications. But this
solution avoids a situation in which an initiator preemptively sends the third
message multiple times, because it has no good way to determine whether it
has been received. The fourth Quick Mode message contains a hash payload
and a notification payload with a “connected” notify message.

5.18 New Group Mode

Figure 5.21 New Group Mode.

HDR, {HASH, SA}

Responder

2

HDR, {HASH, SA}

1

Initiator

New Group Mode, illustrated in Figure 5.21, is an exchange that uses an
established phase 1 ISAKMP SA to protect the negotiation of a new DiffieHellman group that can then be used in subsequent exchanges. That allows
the peers to negotiate a private group whose parameters are not known,
except to the participants. In subsequent phase 1 exchanges, only the group
description number is required; thus, the specific group parameters are not
sent in an unencrypted message.
A New Group exchange consists of two messages (one message from
the initiator to the responder and one from the responder to the initiator).
Each message consists of an SA payload, used to negotiate the characteristics

118

Demystifying the IPsec Puzzle

of the group, and a hash payload, which authenticates the message.
Figure 5.22 shows the formula used to calculate the New Group hashes.
The New Group attributes open to negotiation are group description,
type, prime, generator(s), curve(s), order, and field size. Those values define
the specifics of the Diffie-Hellman exchange that will establish the shared
secret used in the generation of the key material. The group description
serves as the group’s ID number. The group type attribute is used to specify
whether the group is an MODP or elliptic curve group. The group prime
and group generator attributes are used to define a new MODP group; the
group prime, group generator, group curve, group order, and field size attributes are used to define a new elliptic curve group.

5.19 Informational Exchanges
There are two types of informational exchanges: an unacknowledged informational exchange and an acknowledged informational exchange. An unacknowledged informational exchange is a one-way single message used to send
the peer status or diagnostic information. If an ISAKMP SA has been established between the peers, the ISAKMP SA is used to protect the exchange,
and the exchange is authenticated with a hash payload. Either the initiator or
the responder of the phase 1 or phase 2 exchange can act as the initiator of an
informational exchange. Each informational exchange has a unique message
ID distinct from the phase 2 message ID (if any). The message contains
either a “notify payload” or a “delete payload.” A “notify payload” contains
the identifying number of a predefined status (e.g., “initial contact received”)
or diagnostic (e.g., “invalid payload type”) message. A “delete payload” is
used to notify the peer that an SA has been deleted and contains data identifying the deleted SA.
There are circumstances in which the sender requires confirmation that
the informational message was received. For example, if the message is a
Initiator’s Hash = Keyed HMAC of Message ID,
Initiator’s SA Payload,
With Key = SKEYID_a
Responder’s Hash = Keyed HMAC of Message ID,
Responder’s SA Payload,
With Key = SKEYID_a
Figure 5.22 New Group hash calculations.