A Secure Way to Combine IPsec, NAT & DHCP - Computer Network Security - page 112

Responder

Initiator

HDR, SA

HDR, SA

HDR,K NCE

HDR, KE, ONCE

HDR*, IDii, [CERT,] [ATTCERT,] AUTH

HDR*, IDir, [CERT,] [ATTCERT,] AUTH

Fig. 4. IKE v1 main mode

Security Association and Key Management Protocol) [22] and the IKE v1 standards
and now in the IKE v2 proposition allowing access control and service delegation. In
addition, the flexibility of this type of certificate is what motivate us to use it with
current IPsec implementation and in particular with NAT. We have developed
X.509/XML AC with its PMI (Privilege Management Infrastructure) in E-DHCP
proposition. In the last IKE v1 exchange, the node behind the NAT Server can send
its AC in the authentication phases. The X.509/XML AC is signed through the E-
DHCP server and contains both:

1. The Identity (IP address) of the "client or node" which was allocated by the E-
DHCP Server.
2. The Identity (IP address) of the NAT Server. This will allow end entity to verify
that the NAT Server which he negotiates is the pretending NAT that hides the
original IP address of the client.
Upon receiving this certificate from the responder (an end entity node or even a
NAT server), this entity verifies the authentication message and the AC by verifying
the digital signature of the PKI/PMI certificate authority. Once verified, the responder
can verify all IPsec Packets by replacing the NAT address by the masked IP address
send in the AC. The following lines present an example of the XML AC.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE AttributeCertificate SYSTEM "Applica-
tion1.dtd">
<AttributeCertificate Version="1">
<Issuer>....</ Issuer >
<ApplicationName>Application1
</ApplicationName >
<NetworkConnexion>
<NetworkName>VPNdialer</NetworkName>
<NetworkConnexionType>Unlimited
</NetworkConnexionType >
<NATaddress>137.194.192.2-137.194.192.50