Cisco Cisco IOS Software Release 12.4(23)
Appendix A—IPSec Operation
IPSec Operation
52
Security Target For Cisco IOS IPSec
Public key cryptography
Each party generates a pseudo-random number (a nonce) and encrypts it in the other party's public key.
The ability for each party to compute a keyed hash containing the other peer's nonce, decrypted with the
local private key as well as other publicly and privately available information, authenticates the parties
to each other. This system provides for deniable transactions. That is, either side of the exchange can
plausibly deny that it took part in the exchange. Currently only the RSA public key algorithm is
supported.
The ability for each party to compute a keyed hash containing the other peer's nonce, decrypted with the
local private key as well as other publicly and privately available information, authenticates the parties
to each other. This system provides for deniable transactions. That is, either side of the exchange can
plausibly deny that it took part in the exchange. Currently only the RSA public key algorithm is
supported.
Digital signature
Each device digitally signs a set of data and sends it to the other party. This method is similar to the
previous one, except that it provides nonrepudiation. Currently both the RSA public key algorithm and
the digital signature standard (DSS) are supported.
previous one, except that it provides nonrepudiation. Currently both the RSA public key algorithm and
the digital signature standard (DSS) are supported.
Key Exchange
Both parties must have a shared session key in order to encrypt the IKE tunnel. The Diffie-Hellman
protocol is used to agree on a common session key. The exchange is authenticated as described above to
guard against “man-in-the-middle” attacks.
protocol is used to agree on a common session key. The exchange is authenticated as described above to
guard against “man-in-the-middle” attacks.
These two steps, authentication and key exchange, create the IKE SA, a secure tunnel between the two
devices. One side of the tunnel offers a set of algorithms, and the other side must then accept one of the
offers or reject the entire connection. When the two sides have agreed on which algorithms to use, they
must derive key material to use for IPSec with Authentication Headers (AH), ESP (Encapsulating
Security Payload), or both together (the TOE uses ESP only). IPSec uses a different shared key than IKE.
The IPSec shared key can be derived by using Diffie-Hellman again to ensure perfect forward secrecy,
or by refreshing the shared secret derived from the original Diffie-Hellman exchange that generated the
IKE SA by hashing it with pseudo-random numbers (nonces). The first method provides greater security
but is slower. After this is complete, the IPSec SA is established and the packet flow is passed over the
IPSec SA.
devices. One side of the tunnel offers a set of algorithms, and the other side must then accept one of the
offers or reject the entire connection. When the two sides have agreed on which algorithms to use, they
must derive key material to use for IPSec with Authentication Headers (AH), ESP (Encapsulating
Security Payload), or both together (the TOE uses ESP only). IPSec uses a different shared key than IKE.
The IPSec shared key can be derived by using Diffie-Hellman again to ensure perfect forward secrecy,
or by refreshing the shared secret derived from the original Diffie-Hellman exchange that generated the
IKE SA by hashing it with pseudo-random numbers (nonces). The first method provides greater security
but is slower. After this is complete, the IPSec SA is established and the packet flow is passed over the
IPSec SA.
Figure 10
IPSec and IKE Operation
For example, in
, Bob is trying to securely communicate with Alice. Bob sends his data (IP
packets) toward Alice. When Bob’s internetworking device sees the packet, it checks its security policy
and realizes that the packet should be encrypted. The preconfigured security policy also says that Alice's
internetworking device will be the other endpoint of the IPSec tunnel. Bob’s internetworking device
looks to see if it has an existing IPSec SA with Alice’s internetworking device. If not, then it negotiates
one using IKE. If the two internetworking devices already share an IKE SA, the IPSec SA can be quickly
and immediately generated. If they do not share an IKE SA, one must first be created before negotiation
of the IPSec SAs. As part of this process, the two internetworking devices exchange authentication
credentials, such as digital certificates. A certificate authority that both Bob and Alice’s internetworking
devices trust must sign the certificates beforehand. When the IKE session becomes active, the two
internetworking devices can negotiate the IPSec SA. When the IPSec SA is set up, both internetworking
and realizes that the packet should be encrypted. The preconfigured security policy also says that Alice's
internetworking device will be the other endpoint of the IPSec tunnel. Bob’s internetworking device
looks to see if it has an existing IPSec SA with Alice’s internetworking device. If not, then it negotiates
one using IKE. If the two internetworking devices already share an IKE SA, the IPSec SA can be quickly
and immediately generated. If they do not share an IKE SA, one must first be created before negotiation
of the IPSec SAs. As part of this process, the two internetworking devices exchange authentication
credentials, such as digital certificates. A certificate authority that both Bob and Alice’s internetworking
devices trust must sign the certificates beforehand. When the IKE session becomes active, the two
internetworking devices can negotiate the IPSec SA. When the IPSec SA is set up, both internetworking
Router/firewall
with IPSec TOE
Router/firewall
with IPSec TOE
Router/firewall
with IPSec TOE
Router/firewall
with IPSec TOE
Trusted
network
Untrusted
network
Bob
Clear text
Encrypted text
Encrypted text
Alice
Trusted
network
230601
IKE SA
IPSec SA
IKE SA
IPSec SA
Authenticated, encrypted tunnel