Information Technology Reference
In-Depth Information
ported. In addition, the establishment of SA (Security Association) for other security
protocols (IPsec) can be piggybacked on the Phase 1 IKE exchange.
From authentication's schemes point of difference, digital signature is the only
supported mechanism for certificate based authentication. Shared secret authentica-
tion is still supported.
Thus, IKE v1 and v2 relies on the same mechanisms that power most network se-
curity systems: public and private key cryptography, and keyed hash functions. They
also allow the use of AC (Attribute Certificate) within a Public Key and a Privilege
Management Infrastructures (PKI/PMI).
Even that version 2 of IKE does not interoperate with version 1, but it has enough
of the header format in common that both versions can unambiguously run over the
same UDP port.
4.2.2 IKE v1 Negotiation Issue at NAT and E-DHCP Environment
Generic IPsec process starts with the IKE negotiation which establishes SA and key
agreement (fig.4). The main mode of IKE continues with the negotiation of NONCE
values in the IKE nonce payloads and the DH (Diffie-Hellman) public parameters in
the KE payloads. Now both initiator and responder create the master secret and its
derived keys.
At this point, all payloads (without the HDR payload) will be encrypted with the
derived key protecting ID authentication against ID spoofing attack. The two entities
can exchange identity information using a digital signature algorithm to authenticate
themselves.
The digital signature is not applied to the IKE message. Instead it is applied to a
hash on all information available to both entities. All this information is carried in an
identity payload, authentication payload and a certificate payload.
The second phase of IKE establishes the SA agreement for IPsec treatment for the
IP payloads. Using the SA and key information agreed through the IKE negotiation,
IPsec ESP or AH modes are applied to support confidentiality or integrity of the IP
datagrams.
In the NAT environments, however, applying IPsec transport mode causes a prob-
lem due to the datagram conversion at the NAT server on route to the destination
node. The problem happens at the first phase of the IKE negotiation and at the mode
of IPsec AH operation. In fact, at the fifth and sixth steps of the main mode operations
of IKE (fig.4), both nodes exchange the ID information and hash values (HASH_I and
HASH_R) verifying some information including the ID values. The IP addresses are
usually used as the ID values in this procedure.
The IP translation at the NAT server causes the ID authentication to fail, because
the IP node at the destination is ignorant of the IP translation at the NAT server, and
the verification of the hash value (HASH_I) based on the translated IP address fails.
Thus, the whole IKE negotiation procedure fails.
To inform the responder of the IP address masked behind the IP translation, we
propose to correlate the masked IP address and the IP translated address through an
AC generated by the E-DHCP server. AC was integrated in the ISAKMP (Internet
