|IPSec Suite - Key management|
|Written by Administrator|
|Sunday, 30 September 2001 08:48|
Page 3 of 4
Key management and exchange
To communicate with someone using encryption and authentication services (like those provided by ESP and AH), you need to do three things:
The Security Association (SA)
The first thing IPSec designers solved was actually number three, how to keep track of all the details, keys and encryption algorithms to use. They did it by bundling all together in something called Security Association (SA). An SA groups together all the things you need to know about how to communicate with someone securely. The SA, under IPSec specifies:
An SA is describes all the security relevant aspects of a IPSec channel. It’s like a contract with whoever is at the other end. The SA also has the advantage that it lets you construct classes of security channels. If you need to be a little more careful talking to one party, the rules of your SA can reflect extra caution.
How the SA works with the SPI
The SPI is a number that uniquely identifies an SA. The SPI, together with the SA, makes keeping track of protocols and algorithms easy and automatic. The SPI is an arbitrary 32 bit number your system picks to represent that SA whenever someone negotiates an SA with you – it identifies the SA.
The SPI can not be encrypted in the packet because it is the pointer to the SA which defines how to decrypt a packet. When you negotiate SA, the recipient node assigns an SPI it isn’t already using and preferably one it hasn’t used in a while. It then communicates the SPI to the node with which it negotiated the SA. From then until the SA expires, whenever that node wishes to communicate with yours, it specifies that SPI.
Your node on receipt, looks at the SPI to determine the SA it needs to use. Then it authenticates and/or decrypts the packet according to the rules the SA specifies, using the agreed-upon keys and algorithms to verify that the data did really come from the node it claims, that the data has not been modified (tampered), and that nobody could have been reading the data. The next thing we need is to take a look onto how such a SA is negotiated.
IKE (Internet Key Exchange)
IKE is the IPSec group’s answer to strength key exchange and protocol negotiation. IKE integrates the Internet Security Association and Key Management Protocol (ISAKMP) and a subset of the Oakley key exchange protocol (Diffie-Hellman shared secret). IKE provides a way to:
Key exchange is a closely related process to SA management. Before you can create an SA, you need to exchange keys – IKE wraps them both up together, and deliver them as an integrated package.
Manual key exchange
IPSec’s designers provided an other way to exchange keys. For minimal compatibility, every IPSec system must provide a way for manual keying as well. That means if you wish to use manual key exchange for certain situations, you still can. But IPSec’s designers also assume that in most situations, for large enterprise networks for example, this would be an impractical way.
IKE functions in two phases. In the first phase, two IKE peers establish a secure channel for doing IKE (the IKE SA). In the second phase, the two peers negotiate general purpose SA’s.
Oakley provides three modes of exchanging keying information and SA’s, two in phase one and one in phase two IKE exchanges.
Establishing a secure channel for negotiation
To establish an IKE SA, the initiating node proposes six things:
Perfect forward secrecy
An attacker has a number of opportunities to get hold of the encrypted data, when you pass them around the world over a public network. You can reduce the risk by using larger and larger keys. But the larger the keys, the more complex and slower the encryption and this can impair network performance.
A good compromise is to use reasonably large keys, and changing them quite often. So you need ways to generate new keys the person on the other end can agree on it as well. You must not use keying material from existing keys to generate your new keys. If you do so, and someone gets hold of your current key, he/she would be able to deduce your new key.
What you need is a method to generate a new key that is in no way dependent on the value of the current key. If then someone gets hold of your current key, it gives them only a small piece of the overall picture. Cryptographers call this concept “perfect forward secrecy” – IKE uses a scheme called Diffie-Hellman to achieve this.
A Diffie-Hellman exchange works like this. Every person who wants to use that scheme needs to generate a public/private key pair. Remember: The larger the keys the better the protection but the slower the encryption/decryption, and authentication process. Each of them sends their public key to the other (using an authentication scheme to prevent a “man in the middle” attack). Each of them then combines the public key just received with the own private key, using the Diffie-Hellman algorithm.
You can use the derived key, which has the same value on both sides as either a session key or as a encryption key to encrypt a randomly generated key.
Don’t forget, you even need to authenticate Diffie-Hellman public keys to protect against the “man in the middle” attack. Diffie-Hellman itself does not solve this problem. There are several methods to protect public keys from an attacker. If the key exchange mechanism you use is protected by an authentication scheme, Diffie-Hellman allows you to generate new shared keys to use for symmetric encryption which are independent of older keys – providing perfect forward secrecy.
The pseudo-random function (PRF)
The PFR is just another name for a hash function. In IKE, you can use the PRF both for authentication purposes and to generate additional keying material (as a randomizer).
|Last Updated on Monday, 11 June 2012 10:56|