IPsec
Background
Traditionally, remote working has been achieved by using private dial in networks consisting of remote users dialling in with modems across the
PSTN or by using ISDN to connect with access servers that are situated at the organisation's central point. With the growth of the Internet
until it is almost ubiquitous in its presence, technologies have been developed that allow users to connect to private networks across
the public Internet. This is achieved via the use of Virtual Private Networks (VPN) (or Virtual Private Dialup Networks (VPDN)).
A secure IP tunnel can be set up between the user and the central site. This tunnel looks like any other IP traffic on the public
Internet using the public IP addresses, but contains encrypted IP conversations within the private IP address structure.
The 'umbrella' protocols used for these tunnels include Point-to-Point Tunnelling Protocol (PPTP) and the IPsec suite of protocols.
These protocols have to deal with encrypting the data itself, hiding the private IP addresses, testing for authenticity and testing
for reliability of the data i.e. its integrity. Other protocols used for specific tasks in VPNs include Secure Sockets Layer (SSL),
Lightweight Directory Access Protocol (LDAP) (TCP 389) and RADIUS (UDP 1645)
( RFC 2138).
IPsec Architecture
As the Internet matures so the need for more security grows. IPsec has been developed to address the needs for data security,
integrity, authentication and protection. A series of RFCs covers the IPsec framework and are structured as follows:
The ISAKMP protocol uses TCP/UDP port 500.
Benefits
With layer 2 encryption techniques, devices at the end of each link need to be capable of
encrypting the frames. IPsec operates at layer 3 and so only the devices at the end of the IPsec tunnel need
to have encryption capability.
Other benefits are that QoS is able to be applied to IPsec datagrams, applications do not have to be concerned
with the encryption technologies and IPsec can be managed centrally on the devices such as routers, firewalls
and servers where IPsec is implemented.
IPsec cannot be used to secure multicast or broadcast traffic as 'group key distribution' does not yet exist.
IPsec is sometimes used to refer to the whole security services which includes IKE, and other times the term
IPsec is used to just reference the data security services.
Concepts of IPsec
IPsec encapsulates the concepts of Confidentiality, Integrity, Origin Authentication
and Anti-Replay.
Internet Key Exchange (IKE)
IKE is a hybrid protocol that uses SKEME and Oakley key exchanges inside a framework of ISAKMP
and it can be used with protocols other than IPsec.
When traffic wishes to use a tunnel then an IKE SA is set up before the data SAs (normally IPsec SAs) are set up.
IKE provides authentication of the IPSec peers, negotiates IPSec Security Associations (SA), and establishes IPSec keys.
IKE uses UDP port 500 and is defined in RFC 2409 and is based on three key management
protocols:
- Internet Security Association and Key Management Protocol (ISAKMP) defined in
RFC 2408.
- Oakley key exchange, defined in RFC 2412
- Secure Key Exchange Mechanism (SKEME)
IKE provides the following benefits when used with IPsec:
- Dynamic SA establishment
- Dynamic rekeying so that keys can be expired and recreated thereby reducing the chance of an attacker gaining advantage if
they have managed to crack one key.
- Protection from Replay attacks
- Operation with CA servers.
- Perfect Forward Secrecy (PFS) which ensures that keys are not derived from other keys, therefore each key
is as difficult to crack as another key because they are not dependent on each other in any way.
When IKE is used a special SA is set up between peers that is bi-directional and is used for management i.e. negotiating IPsec SAs
and exchanging keys. The IKE SA can be set up in one of two ways, Main Mode or Aggressive Mode.
In Main Mode, the IKE SA is set up in the following manner:
- The initiating station sends transform(s) and a cookie that is a hash of the following items:
- Destination IP address
- Source IP address
- Destination port
- Source port
- Nonce - a randomly generated number that the initiator sends. This nonce is hashed along with the
other items using the agreed key and is sent back.
The initiator checks the cookie including the nonce, and rejects any messages which do not have the right nonce.
This helps prevent replay since no third party can predict what the randomly generated nonce is going to be.
- Date
- Time
- The responding station replies with the accepted transform plus the inititial cookie and its own cookie containing the same items
as above but from the responding station's point of view.
- The initiating station then sends its own cookie, the respondent's cookie, its public key, its ID and its nonce which has
been encrypted with the respondent's public key. The ID consists of the following:
- IP address
- DNS name
- User name
- IP address range
- X500 name
- X.509v3 certificate
- The respondent sends its own cookie, the initiator's cookie, its public key, its own ID and its nonce which has been
encryted with the initiator's public key.
- The initiator then sends its own ID, the ID of the respondent, its own nonce, the respondent's nonce which has been encrypted
with the respondent's public key and a value hashed with its own private key.
- Finally, the respondent replies with the ID of the initiator, its own ID, its own nonce encrypted with the initiator's public key
and a value hashed with its own private key.
In Aggressive Mode, the IKE is set up as follows:
- The initiator sends its own cookie and the requested transforms, both of which are encrypted with its own private key. Plus
the initiator sends its own ID, its nonce, the ID of the respondent and a value that is hashed with its own private key.
- The respondent then sends its own cookie, the initiator's cookie and the accepted transforms, all of which are encrypted
with its own private key. Plus it sends its own ID, its nonce, the initiator's nonce,
the initiator's ID and a value that is hashed with its own private key.
- Finally, the initiator replies with its cookie, an acknowledgement of the agreed transforms, all of which being encrypted with
its own private key. Plus, the initiator sends its own ID, the respondent's ID, its nonce, the respondent's nonce,
and a value that is hashed with its own private key.
IKE uses a keepalive to check that peers at each end are still up. The default timer is 600 seconds. If a keepalive
does not receive a reply then 5 attempts are made at 2 second intervals. If there is still no reply, then
the IKE SA is torn down along with any IPsec SAs that may be in place. New traffic will start negotiations again.
There can be an issue with IKE if there is more than one path to a peer e.g. two pairs of routers. The IKE SA is set up between two routers on
one of the paths. If one router should fail then although IP routing may be OK, a new IKE SA will not be set up until the old
SA has timed out. The trick is to run the SA over the new path, HSRP/VRRP can help with this.
Operation of IPsec
IPsec uses the concept of point-to-point peers. These peers share Transform Sets with each other
during the Security Association negotiation process, and these
Transform Sets determine the character of the IPsec session that they share. A Transform Set consists of the following
information:
- The IPsec security protocol (AH or ESP)
- Integrity/Authority algorithm (MD5, SHA-1)
- Encryption Algorithm (DES, 3-DES), although strictly speaking, you do not have to use an encryption algorithm.
Peers may be from different manufacturers, so they use this negotiation process to work out the lowest common denominator
with regards to the features that the peers have been configured to use. Bear in mind that these transform sets are configurable
and operate on a session by session basis and they do not necessarily represent the full capabilities of the device. You may for instance
configure a different transform set for one connection compared to a transform set for another connection.
Negotiation of the IPsec SAs occurs in Quick Mode and operates as follows:
- The initiator sends an SA offer with a nonce which has been encrypted with the respondent's public key and a value that has
been hashed with its own private key.
- The respondent then sends an SA accepted message along with its own nonce which has been encrypted with the initiator's public key,
and a value that has been hashed with its own private key.
- Finally, the initiator hashes its own nonce and the respondent's nonce with its own private key.
Once the lowest common denominator of features has been successfully established two uni-directional Security Associations (SA)
are set up between the peers. An SA is a uni-directional logical tunnel between the peers that protects data using the features
listed in the transform set. An SA contains the following information:
- IP address
- Security Protocol
- Encryption algorithm
- Key
- Traffic flow description e.g. port numbers etc.
- A 32-bit Security Parameter Index (SPI) that, along with the peer's
IP address, identifies the SA. If you use IKE, then this is a randomly generated number.
- Timers and counters that identify the lifetime of the SA. Using IKE with IPsec allows the SA to be refreshed.
- 64-bit Sequence numbers that are used to detect Replay attacks.
There can be multiple SAs per peer pair and they can be manually set up or dynamically created via IKE.
There are two types of SA:
- Transport Mode SA - this operates between hosts and is not very secure because the original source
and destination IP addresses are readable,
i.e. the hosts do their own AH encapsulation of their data.
A risk exists because the IPsec header sits within the original IP header. This
allows an attacker to make intelligent guesses as to where servers are on a network (busiest IP addresses) and begin to
build a picture of the network.
- Tunnel Mode SA - this operates normally between routers/firewalls or router to host and are used in the VPN environment.
These are often called Security Gateways or IPsec Gateways because the gateways are providing
AH/ESP services to other hosts. This type of SA
is more secure because a new IP header unrelated to the hosts using the tunnel,
is created around the IPsec datagram. The original IP header is included
within the encrypted IPsec datagram and so the originating devices addresses are hidden.
There are in fact two IPsec security services that are used for SAs and they operate in Transport or Tunnel mode. One is called
Authentication Header (AH) and the other is called Encapsulated Security Payload (ESP).
Authentication Header (AH)
Authentication Header (AH) ( RFC 2402)
gives you integrity and authentication using HMACs such as MD5 and SHA-1. AH checks the integrity of the whole IP datagram including
the IP header itself, it then adds an extra header containing the authenticated data (keyed digest of the whole datagram)
within the existing IP datagram and uses the IP protocol number 51. AH checks for authentication, integrity and replay.
AH is built into IPv6!
Because AH hashes on everything in the datagram including the destination and source IP addresses, you cannot use AH when you are
using NAT because NAT changes the IP addresses after AH has done its bit so when the receiver does the AH hash, the value
of the hash changes and therefore the packet is not authenticated.
Encapsulated Security Payload (ESP)
Encapsulated Security Payload (ESP) ( RFC 2406)
provides confidentiality in addition to integrity and authentication, however it does not check the integrity
of the IP header ESP hashes on the payload only, so that
integrity is checked on the payload only (thereby saving CPU time). ESP use IP protocol number 50.
When ESP is used in conjunction with NAT, NAT can change the IP addresses however NAT also modifies the checksum
when it does this. The checksum is part of what ESP hashes on so authentication at the other end will fail. If
NAT does NOT modify the checksum after changing the IP address, then TCP/UDP verificaton will fail. In this situation
you have to find a way for the peers to ignore the checksums of the packets! As it happens ESP in combination with Tunnel Mode
provides a solution because the checksum is ignored.
Some transform sets are set up to use both AH and ESP so that the benefits of
both services can be realised.
If a transform set specifies both AH and ESP then two pairs of uni-directional SAs will be set up because you cannot implement
both AH and ESP on one SA. This is important
when you are using certain IP protocols such as OSPF which uses a different IP protocol number (i.e. 89), the two protocols
cannot therefore exist side by side, this is why IPsec cannot support broadcast and multicast traffic directly, routing protocols
rely on broadcasts, so does DHCP/Bootp. The IP helper can be used to deal with DHCP requests and setting up an IP tunnel (using GRE)
within the IPsec tunnel is a way around sending broadcast/multicast information through the IPsec tunnel.
Overview of IPsec and IKE operating together
Where IPsec and IKE are in operation a typical example of the steps involved could look like this:
- Peer P detects that traffic wishes to use an IPsec tunnel to peer Q.
- Peer P initiates an IKE SA with peer Q.
- A transform set is issued by peer P for the IKE SA
- A transform set is issued by peer Q for the IKE SA
- On agreement of the transform set, peer P sends their digital certificate across the IKE SA
- Peer Q sends their digital certificate across the same bi-directional IKE SA.
- Peer P and Peer Q then exchange Diffie-hellman numbers that are digitally signed so that they can establish a shared key that they
can be confident genuinely comes from the other peer.
- Peers P and Q verify each other's signature using each other's public key.
- The shared key is calculated using the Diffie-Hellman numbers.
- The IKE SA is now established
- Peer P sends a transform set on the IKE SA.
- Peer Q sends a transform set on the IKE SA and peers P and Q decide the lowest common set.
- Peer P now initiates a uni-directional IPsec SA for data transfer
- If Peer Q needs to send data then peer Q initiates its own uni-directional IPsec SA.
- The Diffie-Hellman key exchange is used again for P and Q to negotiate a shared key, because IKE is being used, the shared
key derived at this stage is totally independent of the IKE shared key.
- Data is now sent over the IPsec SAs.
- As the IPsec SAs near expiration as defined by their timers, IKE creates new IPsec SAs and data transfer continues seamlessly.
|
