TCP/IP Tutorial and Technical Overview - IBM Redbooks

authority using a protocol such as LDAP, or it can query a secure DNS server, or
it can maintain a secure local cache that maps previously used certificates to
their respective ID values, or it can send an ISAKMP Certificate Request
message to its peer, who must then immediately send its certificate to the
requester.
Note: The method for obtaining a certificate is a local option, and is not
defined as part of IKE. In particular, it is a local responsibility of the receiver to
check that the certificate in question is still valid and has not been revoked.
There are several points to bear in mind:
► At this stage of the process, all ISAKMP payloads, whether in phase 1 or
phase 2, are encrypted, using the encryption algorithm (negotiated in
messages 1 and 2) and the keys (derived from the information in messages 3
and 4). The ISAKMP header itself, however, is still transmitted in the clear.
► In phase 1, IPSec's ESP protocol is not used; that is, there is no ESP header.
The recipient uses the encryption bit in the Flags field of the ISAKMP header
to determine if encryption has been applied to the message. The pair of
values , which serve as an SPI for phase 1 exchanges,
provide a pointer to the correct algorithm and key to be used to decrypt the
message.
► The digital signature, if used, is not applied to the ISAKMP message itself.
Instead, it is applied to a hash of information that is available to both Host-A
and Host-B.
► The identity carried in the identity payload does not necessarily bear any
relationship to the source IP address; however, the identity carried in the
identity payload must be the identity to which the certificate, if used, applies.
Host-A (the initiator) generates the following hash function, and then places the
result in the Signature Payload field:
HASH_I = prf(SKEYID, g x , g y , CookieA, CookieB, SA p, ID A)
If digital signatures were used for authentication, this hash will also be signed by
Host-A.
ID A is Host-A's identity information that was transmitted in the identity payload of
this message, and SA p is the entire body of the SA payload that was sent by
Host-A in message 1, including all proposals and all transforms proposed by
Host-A. The cookies, public Diffie-Hellman values, and SKEYID were explicitly
carried in messages 1 through 4, or were derived from their contents.
838 TCP/IP Tutorial and Technical Overview