TCP/IP Tutorial and Technical Overview - IBM Redbooks

Proposal Payload Host-B's Proposal Payload specifies the protocol
PROTO_ISAKMP and sets the SPI value to 0.
Transform Payload The Transform Payload specifies KEY_OAKLEY. For
the KEY_OAKLEY transform, the attributes that were
accepted from the proposal offered by Host-A are
copied into the appropriate fields.
At this point, the properties of the ISAKMP Security Association have been
agreed to by Host-A and Host-B. The identity of the ISAKMP SA has been set
equal to the pair . However, the identities of the parties
claiming to be Host-A and Host-B have not yet been authoritatively verified.
IKE phase 1, message 3
The third message of the phase 1 ISAKMP exchange begins the exchange of the
information from which the cryptographic keys will eventually be derived (see
Figure 22-39 on page 836).
The ISAKMP payload exchanges two types of information.
Important: None of the messages themselves carry the actual cryptographic
keys. Instead, they carry inputs that will be used by Host-A and Host-B to
derive the keys locally.
Diffie-Hellman public value
The Diffie-Hellman public value g x from the initiator.
The exponent x in the public value is the private value
that must be kept secret.
Nonce The nonce N i from the initiator. (Nonce is a name for a
value that is considered to be random according to
some very strict mathematical guidelines.)
ID If the RSA public key is used for authentication, the
nonces are encrypted with the public key of the other
party. Likewise for the IDs of either party, which are
then also exchanged at this stage.
If authentication with revised RSA public key is used,
the KE and ID payloads are encrypted with a secret
key that is derived from the nonces and the encryption
algorithm agreed to in messages 1 and 2, thus
avoiding one CPU-intensive public key operation.
Chapter 22. TCP/IP security 835