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:

• Negotiate the protocols, encryption algorithms, and keys to use
• Provide a way to exchange keys easily
• Keep track of all the negotiated parameters

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:

• The mode of the authentication algorithm used in the AH and the keys to that authentication algorithm
• The mode of the ESP encryption algorithm and the keys to that encryption algorithm
• How you authenticate your communications (using what protocol, encryption algorithm and keys)
• The presence and size of (or absence of) any cryptographic synchronization to be used in that encryption algorithm.
• How often those keys must be changed (in order to keep the communication secure)
• The lifetime of the SA itself
• The authentication algorithm, mode, and transform for use in ESP plus the keys to be used by that algorithm
• The SA source address
• A sensitive level descriptor

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:

• Agree on protocols, algorithms, and keys to use
• Authenticate the identity with whomever you would like to communicate
• Manage those keys after they have been agreed upon
• Exchange material for generating those keys safely

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 phases

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.

IKE modes

Oakley provides three modes of exchanging keying information and SA’s, two in phase one and one in phase two IKE exchanges.

• Main mode accomplishes a phase one IKE key exchange by establishing a secure channel
• Aggressive mode is another mode of accomplishing a phase one IKE key exchange. It is a little simpler and faster than main mode, but it does not provide identity protection for negotiating nodes. It uses three instead of six packets generally used in main mode IKE key exchange
• Quick mode accomplishes a phase two exchange by negotiating an SA for general purpose communications

Establishing a secure channel for negotiation

To establish an IKE SA, the initiating node proposes six things:

• Encryption algorithms
• Hash algorithms (to reduce data for signing)
• Authentication method
• Information about a group over which to do a Diffie-Hellman exchange
• A pseudo-random function (PRF) uses to hash certain values during the key exchange for verification purposes (this is optional, you can also just use the hash algorithm)
• The type of protection to use

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.

Diffie-Hellman

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.
The result is the same on both sides – but no one else in the world can come up with the same value because the result is also dependent on the private key, which remains secret. As you can see, it is not only important to authenticate the public key of your opponent but to keep your private very, very safe. You should improve the security of your private key by protecting it with a password, or better, with a long passphrase.

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.
The very interesting point is: You use a public/private scheme to agree upon a IPSec shared secret (the Diffie-Hellman key – the session key) but you then use this session key in combination with a symmetric algorithm to protect your data. Guess you can already see the advantage – symmetric algorithms are much faster than asymmetric algorithms (factor 1000) – this solution has a big impact on network performance.

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).