This section provides details of the IPsec protocols which FreeS/WAN implements
The basic idea of IPsec is to provide security functions, authentication and encryption , at the IP (Internet Protocol) level. This requires a higher-level protocol (IKE) to set things up for the IP-level services (ESP and AH).
Three protocols are used in an IPsec implementation:
The term "IPsec" (also written as IPSEC) is slightly ambiguous. In some contexts, it includes all three of the above but in other contexts it refers only to AH and ESP.
Authentication and encryption functions for network data can, of course, be provided at other levels. Many security protocols work at levels above IP.
and so on. Other techniques work at levels below IP. For example, data on a communications circuit or an entire network can be encrypted by specialised hardware. This is common practice in high-security applications.
There are, however, advantages to doing it at the IP level instead of, or as well as, at other levels.
IPsec is the most general way to provide these services for the Internet.
IPsec, however, can protect any protocol running above IP and any medium which IP runs over. More to the point, it can protect a mixture of application protocols running over a complex combination of media. This is the normal situation for Internet communication; IPsec is the only general solution.
IPsec can also provide some security services "in the background", with no visible impact on users. To use PGP encryption and signatures on mail, for example, the user must at least:
These systems can be designed so that the burden on users is not onerous, but any system will place some requirements on users. No such system can hope to be secure if users are sloppy about meeting those requirements. The author has seen username and password stuck on terminals with post-it notes in an allegedly secure environment, for example.
IPsec is designed to secure IP links between machines. It does that well, but it is important to remember that there are many things it does not do. Some of the important limitations are:
Of course, there is another side to this. IPsec can be a powerful tool for improving system and network security. For example, requiring packet authentication makes various spoofing attacks harder and IPsec tunnels can be extremely useful for secure remote administration of various things.
For example, if you need mail encrypted from the sender's desktop to the recipient's desktop and decryptable only by the recipient, use PGP or another such system. IPsec can encrypt any or all of the links involved -- between the two mail servers, or between either server and its clients. It could even be used to secure a direct IP link from the sender's desktop machine to the recipient's, cutting out any sort of network snoop. What it cannot ensure is end-to-end user-to-user security. If only IPsec is used to secure mail, then anyone with appropriate privileges on any machine where that mail is stored (at either end or on any store-and-forward servers in the path) can read it.
In another common setup, IPsec encrypts packets at a security gateway machine as they leave the sender's site and decrypts them on arrival at the gateway to the recipient's site. This does provide a useful security service -- only encrypted data is passed over the Internet -- but it does not even come close to providing an end-to-end service. In particular, anyone with appropriate privileges on either site's LAN can intercept the message in unencrypted form.
Note, however, that IPsec authentication of the underlying communication can make various attacks on higher-level protocols more difficult. In particular, authentication prevents man-in-the-middle attacks.
IPsec shifts the ground for DoS attacks; the attacks possible against systems using IPsec are different than those that might be used against other systems. It does not, however, eliminate the possibility of such attacks.
IPsec is not designed to defend against this. Partial defenses are certainly possible, and some are described below, but it is not clear that any complete defense can be provided.
While IPsec does not provide all functions of a mail encryption package, it can encrypt your mail. In particular, it can ensure that all mail passing between a pair or a group of sites is encrypted. An attacker looking only at external traffic, without access to anything on or behind the IPsec gateway, cannot read your mail. He or she is stymied by IPsec just as he or she would be by PGP.
The advantage is that IPsec can provide the same protection for anything transmitted over IP. In a corporate network example, PGP lets the branch offices exchange secure mail with head office. SSL and SSH allow them to securely view web pages, connect as terminals to machines, and so on. IPsec can support all those applications, plus database queries, file sharing (NFS or Windows), other protocols encapsulated in IP (Netware, Appletalk, ...), phone-over-IP, video-over-IP, ... anything-over-IP. The only limitation is that IP Multicast is not yet supported, though there are Internet Draft documents for that.
IPsec creates secure tunnels through untrusted networks . Sites connected by these tunnels form VPNs, Virtual Private Networks.
IPsec gateways can be installed wherever they are required.
Which of these, or of the many other possible variants, to use is up to you. IPsec provides mechanisms; you provide the policy .
No end user action is required for IPsec security to be used; they don't even have to know about it. The site administrators, of course, do have to know about it and to put some effort into making it work. Poor administration can compromise IPsec as badly as the post-it notes mentioned above. It seems reasonable, though, for organisations to hope their system administrators are generally both more security-conscious than end users and more able to follow computer security procedures. If not, at least there are fewer of them to educate or replace.
IPsec can be, and often should be, used with along with security protocols at other levels. If two sites communicate with each other via the Internet, then IPsec is the obvious way to protect that communication. If two others have a direct link between them, either link encryption or IPsec would make sense. Choose one or use both. Whatever you use at and below the IP level, use other things as required above that level. Whatever you use above the IP level, consider what can be done with IPsec to make attacks on the higher levels harder. For example, man-in-the-middle attacks on various protocols become difficult if authentication at packet level is in use on the potential victims' communication channel.
Where appropriate, IPsec can provide authentication without encryption. One might do this, for example:
Authentication has lower overheads than encryption.
The protocols provide four ways to build such connections, using either an AH-only connection or ESP using null encryption, and in either manually or automatically keyed mode. FreeS/WAN supports only one of these, manually keyed AH-only connections, and we do not recommend using that. Our reasons are discussed under Resisting traffic analysis a few sections further along.
Originally, the IPsec encryption protocol ESP didn't do integrity checking. It only did encryption. Steve Bellovin found many ways to attack ESP used without authentication. See his paper Problem areas for the IP Security Protocols. To make a secure connection, you had to add an AH Authentication Header as well as ESP. Rather than incur the overhead of several layers (and rather than provide an ESP layer that didn't actually protect the traffic), the IPsec working group built integrity and replay checking directly into ESP.
Today, typical usage is one of:
Other variants are allowed by the standard, but not much used:
There are fairly frequent suggestions that AH be dropped entirely from the IPsec specifications since ESP and null encryption can handle that situation. It is not clear whether this will occur. My guess is that it is unlikely.
The above describes combinations possible on a single IPsec connection. In a complex network you may have several layers of IPsec in play, with any of the above combinations at each layer.
For example, a connection from a desktop machine to a database server might require AH authentication. Working with other host, network and database security measures, AH might be just the thing for access control. You might decide not to use ESP encryption on such packets, since it uses resources and might complicate network debugging. Within the site where the server is, then, only AH would be used on those packets.
Users at another office, however, might have their whole connection (AH headers and all) passing over an IPsec tunnel connecting their office to the one with the database server. Such a tunnel should use ESP encryption and authentication. You need authentication in this layer because without authentication the encryption is vulnerable and the gateway cannot verify the AH authentication. The AH is between client and database server; the gateways aren't party to it.
In this situation, some packets would get multiple layers of IPsec applied to them, AH on an end-to-end client-to-server basis and ESP from one office's security gateway to the other.
Traffic analysis is the attempt to derive useful intelligence from encrypted traffic without breaking the encryption.
Is your CEO exchanging email with a venture capital firm? With bankruptcy trustees? With an executive recruiting agency? With the holder of some important patents? If an eavesdropper learns about any of those, then he has interesting intelligence on your company, whether or not he can read the messages themselves.
Except in the simplest cases, traffic analysis is hard to do well. It requires both considerable resources and considerable analytic skill. However, intelligence agencies of various nations have been doing it for centuries and many of them are likely quite good at it by now. Various commercial organisations, especially those working on "targeted marketing" may also be quite good at analysing certain types of traffic.
In general, defending against traffic analysis is also difficult. Inventing a really good defense could get you a PhD and some interesting job offers.
IPsec is not designed to stop traffic analysis and we know of no plausible method of extending it to do so. That said, there are ways to make traffic analysis harder. This section describes them.
One might choose to use encryption even where it appears unnecessary in order to make analysis more difficult. Consider two offices which pass a small volume of business data between them using IPsec and also transfer large volumes of Usenet news. At first glance, it would seem silly to encrypt the newsfeed, except possibly for any newsgroups that are internal to the company. Why encrypt data that is all publicly available from many sites?
However, if we encrypt a lot of news and send it down the same connection as our business data, we make traffic analysis much harder. A snoop cannot now make inferences based on patterns in the volume, direction, sizes, sender, destination, or timing of our business messages. Those messages are hidden in a mass of news messages encapsulated in the same way.
If we're going to do this we need to ensure that keys change often enough to remain secure even with high volumes and with the adversary able to get plaintext of much of the data. We also need to look at other attacks this might open up. For example, can the adversary use a chosen plaintext attack, deliberately posting news articles which, when we receive and encrypt them, will help break our encryption? Or can he block our business data transmission by flooding us with silly news articles? Or ...
Also, note that this does not provide complete protection against traffic analysis. A clever adversary might still deduce useful intelligence from statistical analysis (perhaps comparing the input newsfeed to encrypted output, or comparing the streams we send to different branch offices), or by looking for small packets which might indicate establishment of TCP connections, or ...
As a general rule, though, one can improve resistance to traffic analysis by encrypting as much traffic as possible rather than only as much as seems necessary.
It may also help to use fewer tunnels. For example, if all you actually need encrypted is connections between:
You might build one tunnel per mail server and one per remote database user, restricting traffic to those applications. This gives the traffic analyst some information, however. He or she can distinguish the tunnels by looking at information in the ESP header and, given that distinction and the patterns of tunnel usage, might be able to figure out something useful. Perhaps not, but why take the risk?
We suggest instead that you build one tunnel per branch office, encrypting everything passing from head office to branches. This has a number of advantages:
Of course you might also want to add additional tunnels. For example, if some of the database data is confidential and should not be exposed even within the company, then you need protection from the user's desktop to the database server. We suggest you do that in whatever way seems appropriate -- IPsec, SSH or SSL might fit -- but, whatever you choose, pass it between locations via a gateway-to-gateway IPsec tunnel to provide some resistance to traffic analysis.
IPsec combines a number of cryptographic techniques, all of them well-known and well-analyzed. The overall design approach was conservative; no new or poorly-understood components were included.
This section gives a brief overview of each technique. It is intended only as an introduction. There is more information, and links to related topics, in our glossary. See also our bibliography and cryptography web links.
The encryption in the ESP encapsulation protocol is done with a block cipher.
We do not implement single DES. It is insecure. Our default, and currently only, block cipher is triple DES .
The Rijndael block cipher has just won the AES competition to choose a relacement for DES. It will almost certainly be added to FreeS/WAN and to other IPsec implementations.
IPsec packet authentication is done with the HMAC construct. This is not just a hash of the packet data, but a more complex operation which uses both a hashing algorithm (MD5 or SHA) and a key. It therefore does more than a simple hash would. A simple hash would only tell you that the packet data was not changed in transit, or that whoever changed it also regenerated the hash. An HMAC also tells you that the sender knew the HMAC key.
For IPsec HMAC, the output of the hash algorithm is truncated to 96 bits. This saves some space in the packets. More important, it prevents an attacker from seeing all the hash output bits and perhaps creating some sort of attack based on that knowledge.
The Diffie-Hellman key agreement protocol allows two parties (A and B or Alice and Bob) to agree on a key in such a way that an eavesdropper who intercepts the entire conversation cannot learn the key.
The protocol is based on the discrete logarithm problem and is therefore thought to be secure. Mathematicians have been working on that problem for years and seem no closer to a solution, though there is no proof that an efficient solution is impossible.
The RSA algorithm (named for its inventors -- Rivest, Shamir and Adleman) is a very widely used public key cryptographic technique. It is used in IPsec as one method of authenticating gateways for Diffie-Hellman key negotiation.
There are three protocols used in an IPsec implementation:
The term "IPsec" is slightly ambiguous. In some contexts, it includes all three of the above but in other contexts it refers only to AH and ESP.
The IKE protocol sets up IPsec (ESP or AH) connections after negotiating appropriate parameters (algorithms to be used, keys, connection lifetimes) for them. This is done by exchanging packets on UDP port 500 between the two gateways.
IKE (RFC 2409) was the outcome of a long, complex process in which quite a number of protocols were proposed and debated. Oversimplifying mildly, IKE combines:
For all the details, you would need to read the four RFCs just mentioned (over 200 pages) and a number of others. We give a summary below, but it is far from complete.
IKE negotiations have two phases.
After both IKE phases are complete, you have IPsec SAs to carry your encrypted data. These use the ESP or AH protocols. These protocols do not have ports; ports apply only to UDP or TCP.
The IKE protocol is designed to be extremely flexible. Among the things that can be negotiated (separately for each SA) are:
The protocol also allows implementations to add their own encryption algorithms, authentication algorithms or Diffie-Hellman groups. We do not support any such extensions.
There are a number of complications:
These complications can of course lead to problems, particularly when two different implementations attempt to interoperate. For example, we have seen problems such as:
Despite this, we do interoperate successfully with many implementations, including both Windows 2000 and PGPnet. Details are in our interoperability document.
Here is our Pluto developer explaining some of this on the mailing list:
When one IKE system (for example, Pluto) is negotiating with another
to create an SA, the Initiator proposes a bunch of choices and the
Responder replies with one that it has selected.
The structure of the choices is fairly complicated. An SA payload
contains a list of lists of "Proposals". The outer list is a set of
choices: the selection must be from one element of this list.
Each of these elements is a list of Proposals. A selection must be
made from each of the elements of the inner list. In other words,
*all* of them apply (that is how, for example, both AH and ESP can
apply at once).
Within each of these Proposals is a list of Transforms. For each
Proposal selected, one Transform must be selected (in other words,
each Proposal provides a choice of Transforms).
Each Transform is made up of a list of Attributes describing, well,
attributes. Such as lifetime of the SA. Such as algorithm to be
used. All the Attributes apply to a Transform.
You will have noticed a pattern here: layers alternate between being
disjunctions ("or") and conjunctions ("and").
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
cut back. There must be exactly one Proposal. So this degenerates to
a list of Transforms, one of which must be chosen.
IPsec offers two services, authentication and encryption . These can be used separately but are often used together.
Packet authentication can be provided separately using an Authentication Header, described just below, or it can be included as part of the ESP (Encapsulated Security Payload) service, described in the following section. That service offers encryption as well as authentication.
In IPsec this is done using a block cipher (normally Triple DES for Linux). In the most used setup, keys are automatically negotiated, and periodically re-negotiated, using the IKE (Internet Key Exchange) protocol. In Linux FreeS/WAN this is handled by the Pluto Daemon.
The IPsec protocol offering encryption is ESP, Encapsulated Security Payload. It can also include a packet authentication service.
Note that encryption should always be used with some packet authentication service. Unauthenticated encryption is vulnerable to man-in-the-middle attacks . Also note that encryption does not necessarily prevent traffic analysis.
Packet authentication can be provided separately from encryption by adding an authentication header (AH) after the IP header but before the other headers on the packet. This is the subject of this section. Details are in RFC 2402.
Each of the several headers on a packet header contains a "next protocol" field telling the system what header to look for next. IP headers generally have either TCP or UDP in this field. When IPsec authentication is used, the packet IP header has AH in this field, saying that an Authentication Header comes next. The AH header then has the next header type -- usually TCP, UDP or encapsulated IP.
IPsec packet authentication can be added in transport mode, as a modification of standard IP transport. This is shown in this diagram from the RFC:
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | the on algorithms, authentication algorithms or Diffie-Hellman
groups. We do not support any such extensions.
There are a number of complications:
These complications can of course lead to problems, particularly when two different implementations attempt to interoperate. For example, we have seen problems such as:
Despite this, we do interoperate successfully with many implementations, including both Windows 2000 and PGPnet. Details are in our interoperability document.
Here is our Pluto developer explaining some of this on the mailing list:
When one IKE system (for example, Pluto) is negotiating with another
to create an SA, the Initiator proposes a bunch of choices and the
Responder replies with one that it has selected.
The structure of the choices is fairly complicated. An SA payload
contains a list of lists of "Proposals". The outer list is a set of
choices: the selection must be from one element of this list.
Each of these elements is a list of Proposals. A selection must be
made from each of the elements of the inner list. In other words,
*all* of them apply (that is how, for example, both AH and ESP can
apply at once).
Within each of these Proposals is a list of Transforms. For each
Proposal selected, one Transform must be selected (in other words,
each Proposal provides a choice of Transforms).
Each Transform is made up of a list of Attributes describing, well,
attributes. Such as lifetime of the SA. Such as algorithm to be
used. All the Attributes apply to a Transform.
You will have noticed a pattern here: layers alternate between being
disjunctions ("or") and conjunctions ("and").
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
cut back. There must be exactly one Proposal. So this degenerates to
a list of Transforms, one of which must be chosen.
IPsec offers two services, authentication and encryption . These can be used separately but are often used together.
Packet authentication can be provided separately using an Authentication Header, described just below, or it can be included as part of the ESP (Encapsulated Security Payload) service, described in the following section. That service offers encryption as well as authentication.
In IPsec this is done using a block cipher (normally Triple DES for Linux). In the most used setup, keys are automatically negotiated, and periodically re-negotiated, using the IKE (Internet Key Exchange) protocol. In Linux FreeS/WAN this is handled by the Pluto Daemon.
The IPsec protocol offering encryption is ESP, Encapsulated Security Payload. It can also include a packet authentication service.
Note that encryption should always be used with some packet authentication service. Unauthenticated encryption is vulnerable to man-in-the-middle attacks . Also note that encryption does not necessarily prevent traffic analysis.
Packet authentication can be provided separately from encryption by adding an authentication header (AH) after the IP header but before the other headers on the packet. This is the subject of this section. Details are in RFC 2402.
Each of the several headers on a packet header contains a "next protocol" field telling the system what header to look for next. IP headers generally have either TCP or UDP in this field. When IPsec authentication is used, the packet IP header has AH in this field, saying that an Authentication Header comes next. The AH header then has the next header type -- usually TCP, UDP or encapsulated IP.
IPsec packet authentication can be added in transport mode, as a modification of standard IP transport. This is shown in this diagram from the RFC:
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | the on algorithms, authentication algorithms or Diffie-Hellman
groups. We do not support any such extensions.
There are a number of complications:
These complications can of course lead to problems, particularly when two different implementations attempt to interoperate. For example, we have seen problems such as:
Despite this, we do interoperate successfully with many implementations, including both Windows 2000 and PGPnet. Details are in our interoperability document.
Here is our Pluto developer explaining some of this on the mailing list:
When one IKE system (for example, Pluto) is negotiating with another
to create an SA, the Initiator proposes a bunch of choices and the
Responder replies with one that it has selected.
The structure of the choices is fairly complicated. An SA payload
contains a list of lists of "Proposals". The outer list is a set of
choices: the selection must be from one element of this list.
Each of these elements is a list of Proposals. A selection must be
made from each of the elements of the inner list. In other words,
*all* of them apply (that is how, for example, both AH and ESP can
apply at once).
Within each of these Proposals is a list of Transforms. For each
Proposal selected, one Transform must be selected (in other words,
each Proposal provides a choice of Transforms).
Each Transform is made up of a list of Attributes describing, well,
attributes. Such as lifetime of the SA. Such as algorithm to be
used. All the Attributes apply to a Transform.
You will have noticed a pattern here: layers alternate between being
disjunctions ("or") and conjunctions ("and").
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
cut back. There must be exactly one Proposal. So this degenerates to
a list of Transforms, one of which must be chosen.
IPsec offers two services, authentication and encryption . These can be used separately but are often used together.
Packet authentication can be provided separately using an Authentication Header, described just below, or it can be included as part of the ESP (Encapsulated Security Payload) service, described in the following section. That service offers encryption as well as authentication.
In IPsec this is done using a block cipher (normally Triple DES for Linux). In the most used setup, keys are automatically negotiated, and periodically re-negotiated, using the IKE (Internet Key Exchange) protocol. In Linux FreeS/WAN this is handled by the Pluto Daemon.
The