Information Technology Reference
In-Depth Information
</NATaddress >
<Bandwidth>2 Mbits/s</Bandwidth>
</NetworkConnexion>
<PersonnalInfo>
<Holder>… DN + SN ….</ Holder >
<PrivateIPaddress>137.194.192.2
</PrivateIPaddress >
<DNS>serveraix.ftcom.com</DNS> …
</PersonnalInfo>
<Validity>
<From>2004.12.12.12.12</From>
<To>2005.12.12.12.12</To>
</Validity>
<SerialNumber>1012313281</ SerialNumber >
</ AttributeCertificate>
4.2.3 IKE v2 Negotiation Issue at NAT and E-DHCP Environment
The IKEv2 is very similar to IKEv1 in performing mutual authentication and estab-
lishing security associations. IKEv2 first replaces the eight possible phase 1 ex-
changes with a single exchange that provides identity protection and is based on either
public signature or shared secret keys. In addition, IKEv2 is the only proposal that
was conceived to be simply extensible. In a simple manner, IKEv2 proposes adapting
a simple hash function over all payloads, no matter which authentication methods is
used [13]. As shown in (fig.5), and Like IKEv1, IKEv2 allow authentication throw
AC that can be used to negotiation all NAT parameters.
Responder
Initiator
HDR, SAi1, KE, Ni
1
HDR, SAr1, KE, Nr, [CERTREQ]
2
HDR*, IDi, [CERT,]
[ATTCERT,]
[CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr
3
HDR*, IDi, [CERT,]
[ATTCERT,]
AUTH,
SAr2, TSr
4
Fig. 5.
IKE v2 negotiation
In the first exchange, the two entities negotiate a list of proposed cryptographic al-
gorithm in the SA payload, their DH public values (KE) and random nonces (Ni, Nr).
At this point, the two endpoints begin generating the master secret SKEYSEED and
the derived keys SK_e, SK_a and SK_d. Now, all messages in the second round trip
(except the HDR payload) will be encrypted using the encryption key. The initiator
can now send his identity with the ID (Identity) payload, and a hash of the first round
trip messages using the Authentication (AUTH) payload. The initiator can now send
his X509 identity certificate containing his public key that proves his real identity and
