IPSec assumes that a security association or SA is in place, but does have a mechanism for creating that association. The IETF chose to break the process into two parts: IPSec provides the packet level processing while IKE negotiates security associations. IKE is the mechanism IPSec uses to set up SAs.
IKE can be used for more than just IPSec. IPSec is its first application. It can also be used with S/Mime, SSL, etc.
IKE does several things:
– Negotiates its own policy. IKE has several methods it can use for authentication and encryption. It is very flexible. Part of this is to positively identify the other side of the connection.
– Once it has negotiated an IKE policy, it will perform an exchange of key-material using authenticated Diffie-Hellman.
– After the IKE SA is established, it will negotiated the IPSec SA. It can derive the IPSec key material with a new Diffie Hellman or by a permutation of existing key material.
Summarize that IKE does these 3 things:
- – Identification
- – Negotiation of policy
- – Exchange key material
How IPSec Uses IKE
This is how IPSec and IKE work together.
Sam is trying to securely communicate with Alice. Alice sends her data toward Sam. When Alice’s router sees the packet, it checks its security policy and realizes that the packet should be encrypted. The pre-configured security policy also says that Sam’s router will be the other endpoint of the IPSec tunnel. Alice’s router looks to see if it has an existing IPSec SA with Sam’s router. If not, then it requests one from IKE. If the two routers already share an IKE SA, then the IPSec SA can be quickly and immediately generated. If they do not share an IKE SA, then one must first be created before negotiation of the IPSec SAs. As part of this, the two routers exchange digital certificates. The certificates had to have been signed beforehand by a certificate authority that both Sam and Alice’s routers trust. Once the IKE session is active, now the two routers can negotiate the IPSec security association. After the IPSec SA is set up, both routers have agreed on an encryption algorithm (e.g., DES), an authentication algorithm (e.g., MD5), and have a shared session key. Now, Alice’s router can encrypt Alice’s IP packet, place it into a new IPSec packet and send it to Sam’s router. When Sam’s router receives the IPSec packet, it will look up the IPSec SA, properly process and unpack the original datagram, and forward it on to Sam. While this sounds complicated, it all happens automatically and transparently to both Alice and Sam.
Encryption—DES and 3DES
So the encryption that we’re utilizing here with IPSec, DES and Triple DES are widely adopted standards.
They encrypt plain text, which then becomes a cipher text. DES performs 16 rounds of encryption. Triple DES is going to do a lot more than that.
We’re going to do that encryption again and again and again until you wind up with 168-bit encryption. So you can do this on the client, on the server, on the router, or on the firewall.
Now, obviously, when you’re doing 168 different bits of encryption, you’re going to introduce some latency. You need to consider performance implications when using Triple DES.
Breaking DES Keys
How secure is DES? The common way to break it is to do just an exhaustive search. You just try different possibilities until you find the way to break into it.
So on a general-purpose computer, this could take literally hundreds of years to break into a 56-bit DES.
Some people speculate, though it hasn’t actually been done, that you can make a specialized computer for about a million dollars that could crack into DES in probably 35 minutes. And so that possibility exists.
Now, there are a lot of smart people out there, though, and one of the things that those smart people did is say, “Hey, well, if it takes one computer a long time, maybe it would take less time for a lot of computers.”
So they took a big network that had some CRAYs on it, a whole bunch of PCs, and instead of a screen saver, they put in this little program that, tried passwords when the PC was not active. This led to more thinking that the Internet was made up of lots of computers that could work on the problem simultaneously.
In fact, the Electronic Frontier Foundation and distributed.net did just this. They cracked a 56-bit DES challenge in just 22 hours and 15 minutes. So if DES is not currently insecure, it’ll soon be insecure. So this is why we need to start thinking about Triple DES.
Now, does this mean for your client who has a local hardware shop that he’s doing his encryption at 56-bit DES isn’t safe enough? It probably is safe enough.
Again, you need to take into account the particular costs that you have and how motivated someone’s going to be to break into your particular stream.