TCP/IP Tutorial and Technical Overview - IBM Redbooks

When Host-B receives this message and verifies the hash, both systems can
begin to use the negotiated security protocols to protect their user data streams.
Negotiating multiple Security Associations
It is also possible to negotiate multiple Security Associations, each with its own
set of keying material, within a single three-message Quick Mode exchange.
The message formats are very similar to the previously illustrated ones, so we
only highlight the differences:
► Message 1 carries multiple Security Association payloads, each offering a
range of protection suites.
► HASH_1 covers the entire set of all offered Security Associations carried in
message 1. That is, each Security Association and all of its offered proposals
are included.
► In message 2, for each offered SA, Host-B selects a single protection suite.
That is, if n SAs are open for negotiation, Host-B chooses n protection suites,
one from each proposal.
► As was the case for HASH_1, HASH_2 now covers the entire set of all offered
Security Associations carried in message 1. That is, each Security
Association and all of its offered proposals are included.
► After messages 1 and 2 have been exchanged, Host-A and Host-B generate
the keying material for each of the accepted protection suites, using the same
formulas as in “Generating the keys (phase 2)” on page 844, applied
individually for each accepted SA. Even though the nonces and the public
Diffie-Hellman values are the same for all selected suites, the keying material
derived for each selected protection suite is different because each proposal
has a different SPI.
► Because multiple Security Associations have been negotiated, it is a matter of
local choice as to which one is used to protect a given datagram. A receiving
system must be capable of processing a datagram that is protected by any
SA that has been negotiated. That is, it is legal for a given source host to send
two consecutive datagrams to a destination system, where each datagram
was protected by a different SA.
Using IKE with remote access
The critical element in the remote access scenario is the use of Oakley to identify
the remote host by name, rather than by its dynamically assigned IP address.
After the remote host's identity has been authenticated and the mapping to its
dynamically assigned IP address has been ascertained, the remainder of the
processes are the same as we have described for the other scenarios. For
example, if the corporate intranet is considered to be trusted, the remote host
needs to establish a single SA between itself and the firewall. But if the corporate
Chapter 22. TCP/IP security 845