Unlock document.
This document is partially blurred.
Unlock all pages and 1 million more documents.
Get Access
These two messages concern themselves with the Diffie-Hellman key exchange. Each host
independently computes and exponent and a nonce which is then sent to the other host. This is done
one after the other in messages 3 and 4. Once both the hosts have these values, they compute the Diffie
Hellman key.
Messages 5 and 6
The newly minted session key is put to test in the final two steps in Phase 1 of the IKE. The
5th message is needed for proof of identity. Alice should know that she is talking to Bob and not anyone
else. Similarly Bob needs to know if he really is talking to Alice.
More formally , the proof of identity proves that the sender knows the key associated with
We can notice in the screen shot that the encryption flag is set this time which means that
the encryption of IKE packets begins now. Message 6 is exactly the same as message 5 and the only
differences are in the check sum and source and destination addresses (which are reversed).
Messages 1 and 2 of Phase 2 :
The second phase need not be initiated by the same pair of hosts that initiated the first pair.
The first message constitutes of the pair of cookies agreed upon in Phase 1, a new 32 bit number
chosen by the initiator to distinguish this phase 2 setup and some encrypted traffic which consists of the
new crypto proposal for the IPSec SA, a nonce and the first Diffie-Hellman exponentiation.
pfs_group modp768;
Message 3: The final message of IKE is the acknowledgment from the initiator of the quick mode
along with both the identifiers of Phase 1 and Phase 2 ie, the pair of cookies and the 32 bit identifier for
Phase 2. Once this is done, the actual traffic flows between each of the hosts over the specified
5. The SPI for the SA from 192.168.10.2 and 192.168.13.2 is 0x04f7c653 while that for the
SA from 192.168.13.0 to 192.168.10.2 is 0x0059f5d5.
Nodes 192.168.10.2 and 192.168.13.2 were our communicating hosts.
1 a) The racoon configuration file
path certificate "/etc/certs"; ------> 1
dh_group modp1024; ------> 12
} ------> 13
} ------> 14
sainfo address 192.168.13.0/24 any address 192.168.10.0/24 any{ -------> 15
pfs_group modp768; ------> 16
Line 3: This option specifies that the main mode should be used. Optionally, we can also use the
aggressive mode.
Line 4: Specifies the type of certificate (x509) to be used for authentication purposes and in quotes
specifies the name of the certificate file (cacert.pem) and name of the file containing the private key
(privkey.pem). Both these files would be looked up in the path specified in Line 1.
used is 3DES in this case. Integrity is ensured using the MD5 hashing algorithm and finally
authentication is done using an RSA signature. Line 13 specifies the group to be used for Diffie-
Hellman exponentiations.
Lines 15-20: This block is used during Phase 2 of IKE. Line 15 specifies the end points of the hosts
which will use the IPSec SA. The first address is the source address and the second address is the
1 b) The Setkey Configuration File:
#!/usr/sbin/setkey -f ------>1
# ------>2
# Flush SAD and SPD ------>3
flush; ------>4
direction.
Line 7 informs that we will be using the ESP protocol and that tunnel mode should be used. Also, the
tunnel should be between 10.24.100.37 and 10.24.100.15.
Line 8 and 9 specify the other direction.
Description of IKE using Certificates in the tunnel mode.
and 192.168.10.2. Notice that the ISAKMP SA is first established and the IPSec SA establishment
follows it. As required, the ESP protocol is running in the tunnel mode and the tunnel is setup in each
direction between 10.24.100.15 and 10.24.100.37. We can also see that port 500 is being used for
setting up the ISAKMP SA (Phase 1 ).
Given below is a message-by-message analysis of the IKE using certificates. We will
discuss preshared keys in the next section.
Phase 1 : Identity Protection
To initiate the traffic we just ping the host 192.168.13.2 from the host 192.168.10.2. In the
We should note that the tunnel is set up between the gateways and hence we cannot see
the original IP header which contained the source and destination address as 192.168.10.2 and
192.168.13.2 .
Messages 1 and 2.
The first message of the ISAKMP protocol begins with an Initiator cookie. In this case the
IP address of the initiator is 192.168.10.2 and the packet is destined for 192.168.13.2. The value of the
The major purpose of this message is to send a Crypto Proposal from the first machine to
the second machine to agree upon, for encryption and authentication purposes. In this case the the
encryption algorithm will be 3DES-CBC, Authentication is by using rsa signatures and the hash
algorithm for integrity check is MD5. The proposal also contains the diffie-hellman key exchange
modp group.
Messages 3 and 4:
These messages are used for the actual key exchange. The initiator (in this case
10.24.100.15) computes the first Diffie Hellman exponent and sends it over to its peer (10.24.100.37)
Once both ends have each other's exponents, they compute the session key independently.
The computed key is also a function of the nonces. Nonces are used in this transaction because then, by
Messages 5 and 6:
The newly created session key is put to use in the final two steps in Phase 1 of the IKE. The
5th message is needed for proof of identity. Alice should know that she is talking to Bob and not anyone
else. Similarly Bob needs to know if he really is talking to Alice.
Following is a screen shot that shows this transaction.
It can be seen that the payload itself is completely encrypted this time and the encryption
flag is set. Message 6 is symmetric to message 5 and is also encrypted to protect identities. This ends
the first Phase of IKE and now the ISAKMP SA is setup.
Phase 2: IPSEC SA establishment (Quick Mode)
The Quick Mode is a 3- message protocol which negotiates parameters for the Phase2 SA,
including cryptographic parameters and the SPI for each direction. The SPIs will then be used as
It can be started by any host to which the Secuity Policy applies to. The first message constitutes of the
pair of cookies agreed upon in Phase 1, a new 32 bit number chosen by the initiator to distinguish this
phase 2 setup, a nonce and the first Diffie-Hellman exponentiation, along with some traffic which
consists of the new crypto proposal for the IPSec SA.
Except for the cookies which identify the ISAKMP SA, all the other information is encrypted. The
cookie pair serves as the identifier for Phase 1 SA and this can be common common to multiple IPSec
SAs. Similarly the new 32 bit number serves as the identifier for each of the individual IPSec SAs,
allowed by the policy, as they usually share the same Phase 1 information.
Message 3: The final message of Phase 2 is the acknowledgment from the initiator of the quick mode
along with both the identifiers of Phase 1 and Phase 2 ie, the pair of cookies and the 32 bit identifier for
Phase 2. This message marks the end of IKE and sets up the IPSec SA. The resulting keys will be used
for encryption and integrity for this IPSec session.
Once this is done, the actual traffic flows between each of the hosts over the specified
The first ESP packet is shown in the following screen shot.
We can notice in the above screen shot that there are two ESP packets and one ICMP
packet. The ESP packets correspond to the incoming and outgoing IPSec enabled packets . It is to be
noticed that the ICMP packet is decrypted and sent to the internal nodes at the same interface. Hence,
we are able to capture the incoming packet at the external interface. It is to be noted that we do not see
a corresponding outgoing ICMP packet as the packet is enabled with IPSec before it reaches the
external interface.
2. IPSec provides confidentiality though encryption using 3des and both integrity and
3. Perfect forward secrecy is a property of a protocol in which an intruder who sniffs encrypted
4. In preshared keys method, the keys is a function of the preshared key, sender and responder
cookies, the diffie hellman key, and the nonces while it is a function of the nonces and the diffie
5. SPI for the SA between 10.24.100.15 to 10.24.100.37 is 0x015ed985 while that for the
SA between 10.24.100.24 is 0x04786b7e.
6. No the same configuration will not protect traffic flowing between the other two internal hosts.
This is because, although, the other two hosts have the same respective gateways, they lie in
Note:
The private keys were created using Openssl's genrsa command. Similarly the certificates were also
created using other OpenSSL commands. The following screenshot shows this.
